- 21 3月, 2010 3 次提交
-
-
由 Peter Eisentraut 提交于
-
由 Michael Meskes 提交于
-
由 Bruce Momjian 提交于
did with server-side languages.
-
- 20 3月, 2010 12 次提交
-
-
由 Bruce Momjian 提交于
-
由 Simon Riggs 提交于
In this case, correction is to remove now unused fields from struct. Since these were unused and full of garbage anyway, no version change.
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
由 Tom Lane 提交于
so that we won't try to attach any context printouts to messages that get emitted while exiting. Per report from Dennis Koegel, the context functions won't necessarily work after we've started shutting down the backend, and it seems possible that debug_query_string could be pointing at freed storage as well. The context information doesn't seem particularly relevant to such messages anyway, so there's little lost by suppressing it. Back-patch to all supported branches. I can only demonstrate a crash with log_disconnections messages back to 8.1, but the risk seems real in 8.0 and before anyway.
-
由 Robert Haas 提交于
KaiGai Kohei, with adjustments to the comments.
-
由 Tom Lane 提交于
catalog entries via SearchSysCache and related operations. Although, at the time that these callbacks are called by elog.c, we have not officially aborted the current transaction, it still seems rather risky to initiate any new catalog fetches. In all these cases the needed information is readily available in the caller and so it's just a matter of a bit of extra notation to pass it to the callback. Per crash report from Dennis Koegel. I've concluded that the real fix for his problem is to clear the error context stack at entry to proc_exit, but it still seems like a good idea to make the callbacks a bit less fragile for other cases. Backpatch to 8.4. We could go further back, but the patch doesn't apply cleanly. In the absence of proof that this fixes something and isn't just paranoia, I'm not going to expend the effort.
-
由 Tom Lane 提交于
in the xact field on replay, due to not writing out all the data in the wal log struct.
-
由 Simon Riggs 提交于
Docs were unclear on whether or not database=replication was required, nor did they mention the FATAL error this causes if database parameter is mentioned explicitly, whatever its value.
-
由 Simon Riggs 提交于
was broken for a replication connection and no messages were displayed on either standby or primary, at any debug level. Connection messages needed to diagnose session drop/reconnect events. Use LOG mode for now, discuss lowering in later releases.
-
由 Simon Riggs 提交于
correctly sized and expand comment to explain otherwise undocumented use of replication connection parameter.
-
由 Simon Riggs 提交于
-
- 19 3月, 2010 6 次提交
-
-
由 Simon Riggs 提交于
present since 8.0 was never fully meaningful, since two recovery targets cannot be specified. Refactor recovery target type to make this change and associated code easier to understand. No change in function. Bug report arising from internal support question.
-
由 Simon Riggs 提交于
field into WAL record and reset it from there, rather than using FrozenTransactionId which can lead to some corner case bugs. Problem report and suggested route to a fix from Heikki, details by me.
-
由 Peter Eisentraut 提交于
-
由 Peter Eisentraut 提交于
with a few strategically placed pg_verifymbstr calls.
-
由 Peter Eisentraut 提交于
-
由 Bruce Momjian 提交于
-
- 18 3月, 2010 11 次提交
-
-
由 Tom Lane 提交于
Also make a couple other minor editorial improvements.
-
由 Peter Eisentraut 提交于
In PLy_spi_execute_plan, use the data-type specific Python-to-PostgreSQL conversion function instead of passing everything through InputFunctionCall as a string. The equivalent fix was already done months ago for function parameters and return values, but this other gateway between Python and PostgreSQL was apparently forgotten. As a result, data types that need special treatment, such as bytea, would misbehave when used with plpy.execute.
-
由 Heikki Linnakangas 提交于
in recovery_end_command, it always came out as 0 because InRedo was cleared before recovery_end_command was executed. Also, always take ControlFileLock when reading checkpoint location for %r. The recovery_end_command bug and the missing locking was present in 8.4 as well, that part of this patch will be backported separately.
-
由 Simon Riggs 提交于
-
由 Peter Eisentraut 提交于
This variable is apparently only for Python internally. In newer releases of Python this variable pulls in more and more libraries that users are less likely to have, leading to potential build failures.
-
由 Peter Eisentraut 提交于
-
由 Peter Eisentraut 提交于
-
由 Peter Eisentraut 提交于
-
由 Magnus Hagander 提交于
Fujii Masao
-
由 Peter Eisentraut 提交于
-
由 Tom Lane 提交于
to transformAggregateCall, instead of abusing fields in Aggref to carry them temporarily. No change in functionality but hopefully the code is a bit clearer now. Per gripe from Gokulakannan Somasundaram.
-
- 17 3月, 2010 3 次提交
-
-
由 Tom Lane 提交于
Also fix and uncomment an old example of creating a GIST index, and make a couple of other minor editorial adjustments.
-
由 Simon Riggs 提交于
-
由 Simon Riggs 提交于
-
- 16 3月, 2010 3 次提交
-
-
由 Heikki Linnakangas 提交于
the master is still in recovery. We don't support cascading slaves yet. Patch by Fujii Masao, with slightly changed wording.
-
由 Simon Riggs 提交于
-
由 Simon Riggs 提交于
correct, as described in comments at start of xlog.c
-
- 14 3月, 2010 2 次提交
-
-
由 Tom Lane 提交于
-
由 Peter Eisentraut 提交于
-