Re: AW: AW: WAL-based allocation of XIDs is insecure

Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at> writes:
>> Hmm. Actually, what is written to the log is the *modified* page not
>> its original contents.

> I thus really doubt above statement.

Read the code.

> Each page about to be modified should be written to the txlog once,
> and only once before the first modification after each checkpoint.

Yes, there's only one page dump per page per checkpoint. But the
sequence is (1) make the modification in shmem buffers then (2) make
the XLOG entry.

I believe this is OK since the XLOG entry is flushed before any of
the pages it affects are written out from shmem. Since we have not
changed the storage management policy, it's OK if heap pages contain
changes from uncommitted transactions --- all we must avoid is
inconsistencies (eg not all three pages of a btree split written out),
and redo of the XLOG entry will ensure that for us.

>> However, I'd just as soon have the NEXTXID log records too to be doubly
>> sure. I do now agree that we needn't fsync the NEXTXID records,
>> however.

> I do not really see an additional benefit. If the WAL is busted those
> records are likely busted too.

The point is to make the allocation of XIDs and OIDs work the same way.
In particular, if we are forced to reset the XLOG using what's stored in
pg_control, it would be good if what's stored in pg_control is a value
beyond the last-used XID/OID, not a value less than the last-used ones.

regards, tom lane