| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
in the xact field on replay, due to not writing out all the data in
the wal log struct.
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
correctly sized and expand comment to explain otherwise
undocumented use of replication connection parameter.
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
with a few strategically placed pg_verifymbstr calls.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
the master is still in recovery. We don't support cascading slaves yet.
Patch by Fujii Masao, with slightly changed wording.
|
|
|
|
| |
correct, as described in comments at start of xlog.c
|
| |
|
| |
|
| |
|
|
|
|
| |
Jaime Casanova
|
|
|
|
| |
Add ERRCODE_INVALID_PASSWORD sqlstate error code.
|
|
|
|
|
|
| |
by Dan O'Hara.
Patch by Teodor Sigaev
|
| |
|
|
|
|
|
|
|
|
|
|
| |
unable to read a stats file for reasons other than ENOENT, and having to reset
last_statrequest because it's later than current time in the collector.
Not clear if this will shed any light on the "pgstat wait timeout" business,
but it seems like a good idea in general.
In passing, do some message-style-police work on recently-added
pgstat_reset_shared_counters code.
|
|
|
|
| |
properly; it's been making that comment uglier with each run.
|
|
|
|
|
| |
This resulted in useless extra work during every call of parseRelOptions,
but no bad effects other than that. Noted by Alvaro.
|
|
|
|
|
| |
indexes, rather than printing them twice. Per my gripe when the exclusion
constraint feature was committed.
|
|
|
|
|
|
|
|
|
|
| |
corner cases that come up in certain timezones (apparently, only those with
lots and lots of distinct TZ transition rules, as far as I can gather from
a quick scan of their archives). Per suggestion from Jeevan Chalke.
Back-patch to 8.4. Possibly we need to push this into earlier releases
as well, but I'm hesitant to update them to the 64-bit tzcode without
more thought and testing.
|
|
|
|
|
| |
assertion failure reported by Erik Rijkers, but this alone doesn't explain
the failure.
|
| |
|
|
|
|
|
|
|
|
|
| |
by joining to pg_constraint.conindid, instead of the former technique of
joining indirectly through pg_depend. This is much more straightforward
and probably faster as well. I had originally desisted from changing these
queries when conindid was added because I was worried about losing
performance, but if we join on conrelid as well as conindid then the index
on conrelid can be used when pg_constraint is large.
|
|
|
|
|
| |
exclusion constraints. Not sure how we managed to update the comment for
it in catalogs.sgml but miss this one.
|
|
|
|
| |
Noted while reviewing a patch from KaiGai Kohei.
|
|
|
|
|
|
|
|
|
| |
instead of an exclusive lock.
The change is almost for code cleanup. Since there seems to be no
performance benefits from it, backports should not be needed.
Fujii Masao
|
|
|
|
|
|
|
|
| |
The latter is considered unwarranted chumminess with the implementation,
and can lead to crashes with recent Perl versions.
Report and fix by Tim Bunce. Back-patch to all versions containing the
questionable coding pattern.
|
|
|
|
| |
Samoa, Chile; corrections to recent changes in Paraguay and Bangladesh.
|
|
|
|
| |
these definitions unique, too. It used to use the linenumber but in the rare case of two definitions in one line this was not unique.
|
| |
|
|
|
|
|
|
|
|
| |
--single-transaction are both used and the failure happens in commit,
e.g. failed deferred trigger. Also properly free BEGIN/COMMIT result
structures from --single-transaction.
Per report from Dominic Bevacqua
|
| |
|
|
|
|
|
|
| |
the GSSAPI libraries crash.
Noted by Zdenek Kotala
|
|
|
|
|
|
| |
requires a hostname to function.
Noted by Zdenek Kotala
|
|
|
|
| |
Bangladesh, Mexico, Paraguay.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
when warning about column-level privileges. This is more useful than before
and makes the apparent duplication complained of by Piyush Newe not so
duplicate. Also fix lack of quote marks in a related message text.
Back-patch to 8.4, where column-level privileges were introduced.
Stephen Frost
|
|
|
|
| |
file instead of ~/.psqlrc on startup.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
unless (1) the @ isn't quoted and (2) the filename isn't empty. This guards
against unexpectedly treating usernames or other strings in "flat files"
as inclusion requests, as seen in a recent trouble report from Ed L.
The empty-filename case would be guaranteed to misbehave anyway, because our
subsequent path-munging behavior results in trying to read the directory
containing the current input file.
I think this might finally explain the report at
http://archives.postgresql.org/pgsql-bugs/2004-05/msg00132.php
of a crash after printing "authentication file token too long, skipping",
since I was able to duplicate that message (though not a crash) on a
platform where stdio doesn't refuse to read directories. We never got
far in investigating that problem, but now I'm suspicious that the trigger
condition was an @ in the flat password file.
Back-patch to all active branches since the problem can be demonstrated in all
branches except HEAD. The test case, creating a user named "@", doesn't cause
a problem in HEAD since we got rid of the flat password file. Nonetheless it
seems like a good idea to not consider quoted @ as a file inclusion spec,
so I changed HEAD too.
|