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

Re: [COMMITTERS] pgsql: Implement sharable row-level locks, and use them for foreign key

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [COMMITTERS] pgsql: Implement sharable row-level locks, and use them for foreign key
Date: 2005-04-29 04:17:47
Message-ID: 1745.1114748267@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-committerspgsql-hackers
Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl> writes:
> One point I didn't quite understand was the business about XLogging
> heap_lock_tuple.  I had to reread your mail to -hackers on this issue
> several times to get it (as you can see I don't fully grok the WAL
> rules).  Now, I believe that heap_mark4update was wrong on this, no?
> Only it didn't matter because after a crash nobody cared about the
> stored Xmax.

Well, actually the reason I decided to put in xlogging there was that
I realized it was already broken before.  In the existing code it was
possible to have this scenario:
	* transaction N selects-for-update some tuple, so N goes into
	  the tuple's XMAX.
	* transaction N ends without doing anything else.  Since it's
	  not produced any XLOG entries, xact.c thinks it doesn't need
	  to emit either a COMMIT or ABORT xlog record.
	* therefore, there is no record whatsoever of XID N in XLOG.
	* bgwriter pushes the dirty data page to disk.
	* database crashes.
	* on restart, WAL replay sets the XID counter to N or less,
	  because there is no evidence in the XLOG for N.
	* now there will be a "new" transaction N that is mistakenly
	  considered to own an update lock on the tuple.

While the negative impact of this situation is probably not high,
it's clearly The Wrong Thing.

The MultiXactId patch introduces a second way to have the same
problem, ie a MultiXactId on disk for which there is no evidence
in XLOG, so the MXID might get re-used after restart.

In view of the fact that we want to do 2PC sometime soon, and that
absolutely requires xlogging every lock, I thought that continuing to
try to avoid emitting an xlog record for heap_lock_tuple was just silly.

			regards, tom lane

In response to

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2005-04-29 04:35:19
Subject: Re: [HACKERS] Increased company involvement
Previous:From: Josh BerkusDate: 2005-04-29 03:13:14
Subject: Re: [HACKERS] Increased company involvement

pgsql-committers by date

Next:From: Bruce MomjianDate: 2005-04-29 04:21:39
Subject: pgsql: Fix Borland makefile for libpq and improve it for psql.
Previous:From: Alvaro HerreraDate: 2005-04-28 23:53:27
Subject: Re: [COMMITTERS] pgsql: Implement sharable row-level locks, and use them for foreign key

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