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

Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp> writes:
> Yes there must be XLogFlush() before writing buffers.
> BTW how do we get the next XID if WAL files are corrupted ?

My not-yet-committed changes include storing the latest CheckPoint
record in pg_control (as well as in the WAL files). Recovery from
XLOG disaster will consist of generating a new XLOG that's empty
except for a CheckPoint record based on the one cached in pg_control.
In particular we can extract the nextOid and nextXid fields.

It might be that writing NEXTXID or NEXTOID log records should update
pg_control too with new nextXid/nextOid values --- what do you think?
Otherwise there's a possibility that the stored checkpoint is too far
back to cover all the values used since then. OTOH, we are not going
to be able to guarantee absolute consistency in this disaster recovery
scenario anyway; duplicate XIDs may be the least of one's worries.

Of course, if you lose both XLOG and pg_control, you're still in big
trouble. So it seems we should minimize the number of writes to
pg_control, which is an argument not to update it more than we must.

regards, tom lane