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?

Thanks,
nm

In response to

• Re: foreign key locks, 2nd attempt at 2012-02-27 12:13:32 from Heikki Linnakangas

Responses

• Re: foreign key locks, 2nd attempt at 2012-02-28 07:55:31 from Simon Riggs

pgsql-hackers by date

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