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

2011-05-13 Thread Alexey Klyukin
On May 13, 2011, at 2:07 AM, Alexey Klyukin wrote: > On May 13, 2011, at 1:28 AM, Tom Lane wrote: > >> >> We're not likely to do that, first because it's randomly different from >> the handling of every other system catalog update, and second because it >> would serialize all updates on this ca

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

2011-05-13 Thread Bruce Momjian
Is this a TODO? I don't see it on the TODO list. --- Robert Haas wrote: > On Fri, May 13, 2011 at 12:56 AM, Tom Lane wrote: > > BTW, I thought a bit more about why I didn't like the initial proposal > > in this thread, and

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

2011-05-13 Thread Robert Haas
On Fri, May 13, 2011 at 12:56 AM, Tom Lane wrote: > BTW, I thought a bit more about why I didn't like the initial proposal > in this thread, and the basic objection is this: the AccessShareLock or > RowExclusiveLock we take on the catalog is not meant to provide any > serialization of operations o

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

2011-05-12 Thread Tom Lane
Robert Haas writes: > On Thu, May 12, 2011 at 6:59 PM, Tom Lane wrote: >> 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 indiv

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

2011-05-12 Thread Robert Haas
On Thu, May 12, 2011 at 6:59 PM, Tom Lane wrote: > Robert Haas writes: >> On Thu, May 12, 2011 at 6:28 PM, Tom Lane 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 t

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

2011-05-12 Thread Alexey Klyukin
On May 13, 2011, at 1:28 AM, Tom Lane wrote: > Alexey Klyukin writes: >> After digging in the code I've found that a RowExclusiveLock is acquired on >> a pg_db_role_setting table in AlterSetting(). While the name of the locks >> suggests that it should conflict with itself, it doesn't. After I

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

2011-05-12 Thread Tom Lane
Robert Haas writes: > On Thu, May 12, 2011 at 6:28 PM, Tom Lane 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 non

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

2011-05-12 Thread Robert Haas
On Thu, May 12, 2011 at 6:28 PM, Tom Lane wrote: > Alexey Klyukin writes: >> After digging in the code I've found that a RowExclusiveLock is acquired on >> a pg_db_role_setting table in AlterSetting(). While the name of the locks >> suggests that it should conflict with itself, it doesn't. Afte

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

2011-05-12 Thread Tom Lane
Alexey Klyukin writes: > After digging in the code I've found that a RowExclusiveLock is acquired on a > pg_db_role_setting table in AlterSetting(). While the name of the locks > suggests that it should conflict with itself, it doesn't. After I've replaced > the lock in question with ShareUpdat

[HACKERS] 'tuple concurrently updated' error for alter role ... set

2011-05-12 Thread Alexey Klyukin
Hello, We have recently observed a problem with concurrent execution of ALTER ROLE SET... in several sessions. It's similar to the one from http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=fbcf4b92aa64d4577bcf25925b055316b978744a The result is the 'tuple concurrently updated' er