Horton

Re: foreign key locks, 2nd attempt

Simon Riggs <simon@2ndquadrant.com>

View thread
From: Simon Riggs <simon@2ndQuadrant.com>
To: Gokulakannan Somasundaram <gokul007@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>, Alvaro Herrera <alvherre@commandprompt.com>, Tom Lane <tgl@sss.pgh.pa.us>, Noah Misch <noah@leadboat.com>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2012-03-07T11:11:06Z
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.

On Wed, Mar 7, 2012 at 10:18 AM, Gokulakannan Somasundaram
<gokul007@gmail.com> wrote:
>>
>> Insert, Update and Delete don't take locks they simply mark the tuples
>> they change with an xid. Anybody else wanting to "wait on the lock"
>> just waits on the xid. We do insert a lock row for each xid, but not
>> one per row changed.
>
> I mean the foreign key checks here. They take a Select for Share Lock right.
> That's what we are trying to optimize here. Or am i missing something? So by
> following the suggested methodology, the foreign key checks won't take any
> locks.

Please explain in detail your idea of how it will work.

-- 
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services