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

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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: AW: AW: AW: WAL-based allocation of XIDs is insecure
Date: 2001-03-06 16:58:12
Message-ID: 6189.983897892@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Zeugswetter Andreas SB  <ZeugswetterA(at)wien(dot)spardat(dot)at> writes:
> Is it so hard to swap ? First write page to log then modify in shmem. 
> Then those pages would have additional value, because
> then utilities could do all sorts of things with those pages.

After thinking about this a little, I believe I see why Vadim did it
the way he did.  Suppose we tried to make the code sequence be

	obtain write lock on buffer;
	XLogOriginalPage(buffer);   // copy page to xlog if first since ckpt
	modify buffer;
	XLogInsert(xlog entry for modification);
	mark buffer dirty and release write lock;

so that the saving of the original page is a separate xlog entry from
the modification data.  Looks easy, and it'd sure simplify XLogInsert
a lot.  The only problem is it's wrong.  What if a checkpoint occurs
between the two XLOG records?

The decision whether to log the whole buffer has to be atomic with the
actual entry of the xlog record.  Unless we want to hold the xlog insert
lock for the entire time that we're (eg) splitting a btree page, that
means we log the buffer after the modification work is done, not before.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Peter EisentrautDate: 2001-03-06 17:04:44
Subject: Re: How to shoot yourself in the foot: kill -9 postmaster
Previous:From: Peter EisentrautDate: 2001-03-06 16:57:48
Subject: Re: How to shoot yourself in the foot: kill -9 postmaster

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