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

Re: foreign key locks, 2nd attempt

From: Noah Misch <noah(at)leadboat(dot)com>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>,Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Simon Riggs <simon(at)2ndquadrant(dot)com>,Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: foreign key locks, 2nd attempt
Date: 2012-02-28 00:28:14
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Mon, Feb 27, 2012 at 02:13:32PM +0200, Heikki Linnakangas wrote:
> On 23.02.2012 18:01, Alvaro Herrera wrote:
>> As far as complexity, yeah, it's a lot more complex now -- no question
>> about that.
> How about assigning a new, real, transaction id, to represent the group  
> of transaction ids. The new transaction id would be treated as a  
> subtransaction of the updater, and the xids of the lockers would be  
> stored in the multixact-members slru. That way the multixact structures  
> wouldn't need to survive a crash; you don't care about the shared  
> lockers after a crash, and the xid of the updater would be safely stored  
> as is in the xmax field.
> That way you wouldn't need to handle multixact wraparound, because we  
> already handle xid wraparound, and you wouldn't need to make multixact  
> slrus crash-safe.
> Not sure what the performance implications would be. You would use up  
> xids more quickly, which would require more frequent anti-wraparound  
> vacuuming. And if we just start using real xids as the key to  
> multixact-offsets slru, we would need to extend that a lot more often.  
> But I feel it would probably be acceptable.

When a key locker arrives after the updater and creates this implicit
subtransaction of the updater, how might you arrange for the xid's clog status
to eventually get updated in accordance with the updater's outcome?


In response to


pgsql-hackers by date

Next:From: anarazel@anarazel.deDate: 2012-02-28 00:29:20
Subject: Re: Command Triggers, patch v11
Previous:From: Tom LaneDate: 2012-02-28 00:21:38
Subject: Re: Command Triggers, patch v11

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