Re: a slightly stale comment - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: a slightly stale comment
Date
Msg-id CA+U5nMKjh18rCSkac5Uyr4ZLWUMHG-PO50OZtHJys_3gxKvSuA@mail.gmail.com
Whole thread Raw
In response to a slightly stale comment  (Dan Ports <drkp@csail.mit.edu>)
Responses Re: a slightly stale comment  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Re: a slightly stale comment  (Dan Ports <drkp@csail.mit.edu>)
List pgsql-hackers
On Wed, Mar 7, 2012 at 2:05 AM, Dan Ports <drkp@csail.mit.edu> wrote:
> While mucking around in src/backend/utils/time/tqual.c today, I noticed
> the following comment attached to HeapTupleSatisfiesNow:
>
>  *      mao says 17 march 1993:  the tests in this routine are correct;
>  *      if you think they're not, you're wrong, and you should think
>  *      about it again.  i know, it happened to me.  we don't need to
>  *      check commit time against the start time of this transaction
>  *      because 2ph locking protects us from doing the wrong thing.
>  *      if you mess around here, you'll break serializability.  the only
>  *      problem with this code is that it does the wrong thing for system
>  *      catalog updates, because the catalogs aren't subject to 2ph, so
>  *      the serializability guarantees we provide don't extend to xacts
>  *      that do catalog accesses.  this is unfortunate, but not critical.
>
> Much as I hate to disturb a comment just before its 19th birthday, the
> bit about two-phase locking and serializability hasn't been correct
> since around 1999 (when MVCC was added). :-)

There is much wisdom there and much wisdom in leaving ancient warnings
as we find them.

Are these the words you object to?

"we don't need to
>  *      check commit time against the start time of this transaction
>  *      because 2ph locking protects us from doing the wrong thing."

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: Scaling XLog insertion (was Re: Moving more work outside WALInsertLock)
Next
From: Simon Riggs
Date:
Subject: Re: elegant and effective way for running jobs inside a database