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

Re: SIREAD lock versus ACCESS EXCLUSIVE lock

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Heikki Linnakangas" <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: "Dan Ports" <drkp(at)csail(dot)mit(dot)edu>,<pgsql-hackers(at)postgresql(dot)org>
Subject: Re: SIREAD lock versus ACCESS EXCLUSIVE lock
Date: 2011-04-27 21:09:38
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> On 27.04.2011 22:59, Kevin Grittner wrote:
>> For correct serializable behavior in the face of concurrent DDL
>> execution, I think that a request for a heavyweight ACCESS
>> EXCLUSIVE lock might need to block until all SIREAD locks on the
>> relation have been released.  Picture, for example, what might
>> happen if one transaction acquires some predicate locks, then
>> commits (releasing its heavyweight lock on the table), and before
>> concurrent READ WRITE transactions complete there is a CLUSTER on
>> the table. Or a DROP INDEX.  :-(
> Hmm, could we upgrade all predicate locks to relation-level
> predicate locks instead?
Tied to what backend?  This only comes into play with transactions
which have committed and are not yet able to release their predicate
locks because of overlapping READ WRITE serializable transactions
which are still active.  Until that point the ACCESS SHARE lock (or
stronger) is still there protecting against this.
One way we could push this entirely into the heavyweight locking
system would be for a committing transaction with predicate locks to
somehow cause all overlapping read write serializable transactions
which are still active to acquire an ACCESS SHARE lock on each
relation for which the committing transaction has any predicate
lock(s).  (Unless of course they already hold some lock on a
relevant relation.)  This would need to be done before the
committing transaction released its lock on the relation (which it
must have acquired to read something which would cause it to have a
predicate lock).  Is that feasible?  It seems like a lot of work,
and I'm not sure how one transaction would convince another
process's transaction to acquire the locks.
As an alternative, perhaps we could find a way to leave the relation
locks for a serializable transaction until it's safe to clean up the
predicate locks?  They could be downgraded to ACCESS SHARE if they
are stronger.  They would need to survive beyond not only the commit
of the transaction, but also the termination of the connection. 
They would need to be immune to being chosen as deadlock victims.
Any other ideas?

In response to


pgsql-hackers by date

Next:From: C├ędric VillemainDate: 2011-04-27 21:14:06
Subject: Re: [HACKERS] PostgreSQL Core Team
Previous:From: Alvaro HerreraDate: 2011-04-27 20:54:57
Subject: Re: make world fails

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