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

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

From: Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at>
To: "'Hiroshi Inoue'" <Inoue(at)tpf(dot)co(dot)jp>, "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: AW: AW: WAL-based allocation of XIDs is insecure
Date: 2001-03-06 11:16:34
Message-ID: 11C1E6749A55D411A9670001FA687963368225@sdexcsrv1.f000.d0188.sd.spardat.at (view raw or flat)
Thread:
Lists: pgsql-hackers
> > > 5. We will now run a new transaction with the same XID that was in use
> > > before the crash.  If that transaction commits, then we have a tuple on
> > > disk that will be considered valid --- and should not be.
> > 
> > I do not think this is true. Before any modification to a page the original page will be
> > written to the log (aka physical log).
> 
> Yes there must be XLogFlush() before writing buffers.
> BTW how do we get the next XID if WAL files are corrupted ?

Normally:
1. pg_control checkpoint info
2. checkpoint record in WAL ?
3. then rollforward of WAL

If WAL is corrupt the only way to get a consistent state is to bring the
db into a state as it was during last good checkpoint. But this is only possible
if you can at least read all "physical log" records from WAL.

Failing that, the only way would probably be to scan all heap files for XID's that are 
greater than the XID from checkpoint.

I think the utility Tom has in mind, that resets WAL, will allow you to dump the db
so you can initdb and reload. I don't think it is intended that you can immediately 
resume operation, (unless of course for the mentioned case of an upgrade with
a good checkpoint as last WAL record (== proper shutdown)).

Andreas

pgsql-hackers by date

Next:From: domDate: 2001-03-06 12:30:06
Subject: Re: How to shoot yourself in the foot: kill -9 postmaster
Previous:From: Vince VielhaberDate: 2001-03-06 11:11:46
Subject: Banner links not working (fwd)

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