Simon Riggs <si...@2ndquadrant.com> writes:
> I've applied an absolutely minimal fix on this, which introduces no
> other changes that could cause unforeseen consequences.
This is not what we'd agreed to do, I thought.
Now that I've thought more about this bug, the existing coding is flat
out wrong, with or without correction of the epoch. As you yourself
just wrote in a comment, the checkpoint record logically belongs to the
"redo" point in the WAL stream, not to where it's physically located.
Having it carry a nextXid that belongs to the later point is simply
wrong. Having it carry different nextXids depending on wal_level is
even more wrong.
I can point right now to one misbehavior this causes: if you run a
point-in-time recovery with a stop point somewhere in the middle of the
checkpoint, you should end up with a nextXid corresponding to the stop
point. This hack in LogStandbySnapshot causes you to end up with a
much later nextXid, if you were running hot-standby.
> Others may wish to go further, overriding my patches, as they choose.
Okay, I will take the responsibility for changing this, but it needs to
change. This coding was ill-considered from the word go.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
