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
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 |