Re: foreign key locks, 2nd attempt - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: foreign key locks, 2nd attempt
Date
Msg-id 1332023610-sup-4118@alvh.no-ip.org
Whole thread Raw
In response to Re: foreign key locks, 2nd attempt  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: foreign key locks, 2nd attempt
List pgsql-hackers
Excerpts from Simon Riggs's message of jue mar 15 18:46:44 -0300 2012:
>
> On Thu, Mar 15, 2012 at 1:17 AM, Alvaro Herrera
> <alvherre@commandprompt.com> wrote:
>
> > As things stand today
>
> Can I confirm where we are now? Is there another version of the patch
> coming out soon?

Here is v11.  This version is mainly updated to add pg_upgrade support,
as discussed.  It also contains the README file that was posted earlier
(plus wording fixes per Bruce), a couple of bug fixes, and some comment
updates.

There's also a SRF for inspecting multixact members, pg_get_multixact_members,
but I'm not sure how useful it is for the general user so maybe I'll rip
it out of the patch before committing.

I mentioned elsewhere in the thread that ResetMultiHintBit was bogus: we
don't know, while running the various HeapTupleSatisfies routines, what
kind of lock we hold; so we can't do anything to the tuple beyond
setting HEAP_XMAX_INVALID.  There's probably a good place in page
pruning that could be used to transform multis containing committed
updates into plain no-multi Xmax.

The whole thing can be seen in github here:
https://github.com/alvherre/postgres/tree/fklocks

(While creating this patch I noticed that I had created v10 of the patch
on March 6th but apparently never sent it.)

--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Attachment

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Command Triggers, patch v11
Next
From: Peter Geoghegan
Date:
Subject: Re: Re: pg_stat_statements normalisation without invasive changes to the parser (was: Next steps on pg_stat_statements normalisation)