Robert Haas <robertmh...@gmail.com> writes:
> Any substantive comments, besides the obvious "this is not 9.1 material"?
Now that I've absorbed a bit more caffeine, let's see if I can think
straight this time.
General principle you want to assert: any WAL entry that merely results
in setting a deterministic field to a deterministic value shouldn't need
a FPI, since it is easy to check whether the field has that value and
re-apply the update if needed. The way this would have to work is:
1. Page LSN < WAL location: apply field update, set page LSN = WAL location.
2. Page LSN = WAL location: check if field matches, apply update if not.
3. Page LSN > WAL location: do NOT apply field update or change LSN.
Now the issue is what happens if a torn-page event causes the LSN to be
out of sync with the page contents. If the LSN is too small (ie, the
actual page contents come from some later WAL entry) we may mistakenly
apply action 1 or 2 to bytes that don't actually represent the field we
think they do. Now, that would be all right once we replay the later
WAL entry and replace the page data from its FPI. But there are two
huge risks here: one being that in a PITR operation the user might tell
us to stop short of applying the later WAL entry, and the other being
that in any case we'll have an interval where the page is corrupt, which
is a problem if any hot-standby queries try to look at it.
I think we might be all right with that if we can guarantee that any such
inconsistencies only exist before the system believes that it's reached
a consistent database state, but I'm not quite sure if that's true or
not.
Hmm, no, it doesn't work, because the above argument assumes there is a
later FPI-containing WAL entry at all. Suppose we have a sequence of
several single-field-setting WAL entries, and there is no FPI-containing
WAL entry for the page before end of WAL. We could have a torn page
such that the LSN comes from one of the later entries but the field that
should be set from an earlier entry is old. When we replay the earlier
entry, case 3 will apply, so we do nothing ... incorrectly. And there
will be no FPI to fix it.
It doesn't work.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
