Skip site navigation (1) Skip section navigation (2)

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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>
Cc: Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: AW: WAL-based allocation of XIDs is insecure
Date: 2001-03-06 15:28:56
Message-ID: 5493.983892536@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
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

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2001-03-06 15:33:38
Subject: Re: Proposed WAL changes
Previous:From: Tom LaneDate: 2001-03-06 15:20:35
Subject: Re: AW: WAL-based allocation of XIDs is insecure

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group