Re: foreign key locks, 2nd attempt

Alvaro Herrera <alvherre@commandprompt.com>

From: Alvaro Herrera <alvherre@commandprompt.com>
To: Simon Riggs <simon@2ndquadrant.com>
Cc: Noah Misch <noah@leadboat.com>, Robert Haas <robertmhaas@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2012-03-17T22:45:20Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Try to avoid running with a full fsync request queue.

Attachments

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