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

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

Yeah. That doesn't rise to the level of a "well-considered plan", but
I believe that we could develop a plan around that concept, ie, take a
lock associated with the individual object we are about to operate on.

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 on individual objects within the catalog.
What it's there for is to interlock against operations that are
operating on the catalog as a table, such as VACUUM FULL (which has to
lock out all accesses to the catalog) or REINDEX (which has to lock out
updates). So the catalog-level lock is the right thing and shouldn't be
changed. If we want to interlock updates of individual objects then we
need a different locking concept for that.

regards, tom lane