The following patch has been independently verified as fixing bug 4137.
The problem was that at the very start of archive recovery the %r
parameter in restore_command could be set to a filename later than the
currently requested filename (%f). This could lead to early truncation
of the archived
Simon Riggs wrote:
The problem was that at the very start of archive recovery the %r
parameter in restore_command could be set to a filename later than the
currently requested filename (%f). This could lead to early truncation
of the archived WAL files and would cause warm standby replication to
On Tue, 2008-05-06 at 12:02 +0100, Heikki Linnakangas wrote:
Simon Riggs wrote:
The problem was that at the very start of archive recovery the %r
parameter in restore_command could be set to a filename later than the
currently requested filename (%f). This could lead to early truncation
Simon Riggs wrote:
Falling back to the secondary checkpoint implies we have a corrupted or
absent WAL file, so making recovery startup work correctly won't avoid
the need to re-run the base backup. We'll end with an unrecoverable
error in either case, so it doesn't seem worth attempting to
On Tue, 2008-05-06 at 17:52 +0100, Heikki Linnakangas wrote:
Simon Riggs wrote:
We were already assuming archive files were OK to delete, if before.
The whole of recovery already relies heavily on the alphabetic sorting
property of WAL and associated filenames. Those filenames have been
Simon Riggs wrote:
On Tue, 2008-05-06 at 17:52 +0100, Heikki Linnakangas wrote:
I didn't suggest that alphabetical sorting property is a new assumption;
it sure isn't. The new assumption is that you never call ReadRecord()
for record 0002 before you call it for record 0001 (before initializing
Alvaro Herrera [EMAIL PROTECTED] writes:
Simon Riggs wrote:
On Tue, 2008-04-22 at 15:49 -0400, Alvaro Herrera wrote:
- Three CopySnapshot call sites remain outside snapmgr.c: DoCopy() on
copy.c, ExplainOnePlan() on explain.c and _SPI_execute_plan() on spi.c.
They are there because they grab
I wrote:
Also, I don't think the subtransaction management is correct at all.
BTW, maybe it would make more sense to keep the reference count
management inside ResourceOwners, instead of having a largely
duplicative set of logic in snapmgr.c.
regards, tom lane
--
Sent
On Tue, 2008-05-06 at 21:51 +0100, Heikki Linnakangas wrote:
In fact, what will happen if the checkpoint record's redo pointer points
to an earlier xlog file:
1. The location of the checkpoint record is read by read_backup_label().
Let's say that it's 0005.
2. ReadCheckpointRecord() is
Andrew Dunstan [EMAIL PROTECTED] writes:
[ column privileges patch ]
I looked over this patch with the hope of applying it, but soon despaired.
It needs a great deal more work than I am willing to put into it during
commitfest. There are two absolutely critical must-fix problems:
1. The syntax
Tom, et al,
* Tom Lane ([EMAIL PROTECTED]) wrote:
I'm not sure where we go from here. Your GSOC student has disappeared,
right? Is anyone else willing to take up the patch and work on it?
I'm willing to take it up and work on it. I'm very interested in having
column-level privileges in PG.
Stephen Frost [EMAIL PROTECTED] writes:
* Tom Lane ([EMAIL PROTECTED]) wrote:
I'm not sure where we go from here. Your GSOC student has disappeared,
right? Is anyone else willing to take up the patch and work on it?
I'm willing to take it up and work on it.
Excellent! As you say, you've
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
If we're going to change it, we should make it match GUC's parse_bool,
which has had some actual thought put into it.
Good idea. Do I copy the C code into /psql or somehow share the
function?
Just copy it ---
Tom Lane wrote:
I'm not sure where we go from here. Your GSOC student has disappeared,
right? Is anyone else willing to take up the patch and work on it?
No, he has not disappeared at all. He is going to work on fixing issues
and getting the work up to SQL99
Added to TODO:
o Consider changing error to warning for strings larger than one
megabyte
http://archives.postgresql.org/pgsql-bugs/2008-02/msg00190.php
http://archives.postgresql.org/pgsql-patches/2008-03/msg00062.php
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Added to TODO:
* Allow text search dictionary to filter out only stop words
http://archives.postgresql.org/pgsql-patches/2007-11/msg00081.php
That's a poor description. I thought the TODO was something more like
allow
16 matches
Mail list logo
