Re: [COMMITTERS] pgsql: Improve concurrency of foreign key locking

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [COMMITTERS] pgsql: Improve concurrency of foreign key locking
Date: 2013-01-23 17:58:16
Message-ID: 20130123175816.GC4249@alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

Andrew Dunstan wrote:
>
> On 01/23/2013 10:12 AM, Alvaro Herrera wrote:
> >Improve concurrency of foreign key locking
>
> This error message change looks rather odd, and has my head spinning a bit:
>
> - errmsg("SELECT FOR UPDATE/SHARE cannot be
> applied to the nullable side of an outer join")));
> + errmsg("SELECT FOR UPDATE/SHARE/KEY UPDATE/KEY
> SHARE cannot be applied to the nullable side of an outer join")))
>
> Can't we do better than that?

Basically this message says "a SELECT with a locking clause attached
cannot be blah blah". There are many messages that had the original
code saying "SELECT FOR UPDATE cannot be blah blah", which was later
(8.1) updated to say "SELECT FOR UPDATE/SHARE cannot be blah blah". I
expanded them using the same logic, but maybe there's a better
suggestion? Note that the SELECT reference page now has a subsection
called "The locking clause", so maybe it's okay to use that term now.

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Browse pgsql-committers by date

  From Date Subject
Next Message Kevin Grittner 2013-01-23 19:42:43 pgsql: Fix performance problems with autovacuum truncation in busy work
Previous Message Simon Riggs 2013-01-23 17:48:53 Re: [COMMITTERS] pgsql: Improve concurrency of foreign key locking

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2013-01-23 18:08:41 Re: BUG #6510: A simple prompt is displayed using wrong charset
Previous Message Pavel Stehule 2013-01-23 17:54:36 Re: proposal: fix corner use case of variadic fuctions usage