Horton

Re: foreign key locks, 2nd attempt

Robert Haas <robertmhaas@gmail.com>

View thread
From: Robert Haas <robertmhaas@gmail.com>
To: Noah Misch <noah@leadboat.com>
Cc: Simon Riggs <simon@2ndquadrant.com>, Alvaro Herrera <alvherre@commandprompt.com>, Tom Lane <tgl@sss.pgh.pa.us>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2012-03-15T02:15:22Z
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 14, 2012 at 6:10 PM, Noah Misch <noah@leadboat.com> wrote:
>> Well, post-release, the cat is out of the bag: we'll be stuck with
>> this whether the performance characteristics are acceptable or not.
>> That's why we'd better be as sure as possible before committing to
>> this implementation that there's nothing we can't live with.  It's not
>> like there's any reasonable way to turn this off if you don't like it.
>
> I disagree; we're only carving in stone the FOR KEY SHARE and FOR KEY UPDATE
> syntax additions.  We could even avoid doing that by not documenting them.  A
> later major release could implement them using a completely different
> mechanism or even reduce them to aliases, KEY SHARE = SHARE and KEY UPDATE =
> UPDATE.  To be sure, let's still do a good job the first time.

What I mean is really that, once the release is out, we don't get to
take it back.  Sure, the next release can fix things, but any
regressions will become obstacles to upgrading and pain points for new
users.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company