Horton

Re: 'tuple concurrently updated' error for alter role ... set

Robert Haas <robertmhaas@gmail.com>

View thread
From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Alexey Klyukin <alexk@commandprompt.com>, pgsql-hackers@postgresql.org
Date: 2011-05-13T03:47:42Z
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. Fix possible "tuple concurrently updated" error in ALTER TABLE.

On Thu, May 12, 2011 at 6:59 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Thu, May 12, 2011 at 6:28 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> We're not likely to do that, first because it's randomly different from
>>> the handling of every other system catalog update,
>
>> We have very robust locking of this type for table-related DDL
>> operations and just about none for anything else.  I don't consider
>> the latter to be a feature.
>
> I didn't say it was ;-).  What I *am* saying is that if we're going to
> do anything about this sort of problem, there needs to be a
> well-considered system-wide plan.  Arbitrarily changing the locking
> rules for individual operations is not going to make things better,
> and taking exclusive locks on whole catalogs is definitely not going to
> make things better.

Yes; true.  I'm inclined to say that this is a bug, but not one we're
going to fix before 9.2.  I think it might be about time to get
serious about making an effort to sprinkle the code with a few more
LockDatbaseObject() and LockSharedObject() calls.

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