Re: SIREAD lock versus ACCESS EXCLUSIVE lock

From: Dan Ports <drkp(at)csail(dot)mit(dot)edu>
To: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: heikki(dot)linnakangas(at)enterprisedb(dot)com, tgl(at)sss(dot)pgh(dot)pa(dot)us, simon(at)2ndquadrant(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: SIREAD lock versus ACCESS EXCLUSIVE lock
Date: 2011-06-06 05:58:08
Message-ID: 20110606055808.GB26076@csail.mit.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Jun 05, 2011 at 12:45:41PM -0500, Kevin Grittner wrote:
> Is this possible? If a transaction gets its snapshot while OID of N
> is assigned to relation X, can that transaction wind up seeing an OID
> of N as a reference to relation Y? If not, there aren't any false
> positives possible.

This ought to be possible, assuming that the transaction doesn't try to
read (and take an AccessShareLock on) X.

On the other hand, given all the timing constraints you've noted, I
think it's reasonable to ignore the risk of false positives here. What
you're saying is that we might inadvertently roll back a transaction,
if a table gets dropped and a new table created and assigned the same
OID, and there's an uncommitted transaction that started before the
DROP, *and* certain other conditions hold about the reads and timing of
overlapping transactions.

This combination of conditions seems quite unlikely and I have a hard
time getting too worked up about it. Occasional false positives are
already a fact of life when using SSI.

Dan

--
Dan R. K. Ports MIT CSAIL http://drkp.net/

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2011-06-06 06:00:15 Re: heap vacuum & cleanup locks
Previous Message Darren Duncan 2011-06-06 05:21:20 Re: Range Types and extensions