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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Alexey Klyukin <alexk(at)commandprompt(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: 'tuple concurrently updated' error for alter role ... set
Date: 2011-05-12 22:59:23
Message-ID: 12194.1305241163@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Thu, May 12, 2011 at 6:28 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Grittner 2011-05-12 23:02:03 Re: SSI-related code drift between index_getnext() and heap_hot_search_buffer()
Previous Message Robert Haas 2011-05-12 22:53:56 Re: 'tuple concurrently updated' error for alter role ... set