Horton

Re: foreign key locks, 2nd attempt

Dimitri Fontaine <dimitri@2ndquadrant.fr>

View thread
From: Dimitri Fontaine <dimitri@2ndQuadrant.fr>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Simon Riggs <simon@2ndquadrant.com>, Alvaro Herrera <alvherre@alvh.no-ip.org>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2011-11-21T20:26:55Z
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.

Robert Haas <robertmhaas@gmail.com> writes:
> On Sat, Nov 19, 2011 at 10:36 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> It's already the case that RI triggers require access to special
>> executor features that are not accessible at the SQL level.  I don't
>> think the above argument is a compelling reason for exposing more
>> such features at the SQL level.  All we need is that C-coded functions
>> can get at them somehow.
>
> I kinda agree with Simon.  In general, if we don't need to expose
> something at the SQL level, then sure, let's not.  But it seems weird
> to me to say, well, we have four lock modes internally, and you can
> get to three of them via SQL.  To me, that sort of inconsistency feels
> like a wart.

+1

I know I've already rolled constraint triggers into production, being
able to use FOR KEY SHARE locks would be good.

Regards,
-- 
Dimitri Fontaine
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support