Re: Getting rid of "tuple concurrently updated" elog()s withconcurrent DDLs (at least ALTER TABLE) - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Getting rid of "tuple concurrently updated" elog()s withconcurrent DDLs (at least ALTER TABLE)
Date
Msg-id CAB7nPqSZCkVfibTvx9TYmHYhVtV_vOMNwOpLHnRU85qeiimUaQ@mail.gmail.com
Whole thread Raw
In response to Re: Getting rid of "tuple concurrently updated" elog()s with concurrent DDLs (at least ALTER TABLE)  (Andres Freund <andres@anarazel.de>)
Responses Re: Getting rid of "tuple concurrently updated" elog()s withconcurrent DDLs (at least ALTER TABLE)  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Tue, Dec 26, 2017 at 4:30 PM, Andres Freund <andres@anarazel.de> wrote:
> You're proposing to lock the entire relation against many forms of concurrent DDL, just to get rid of that error?
Thatseems unacceptable.
 
> Isn't the canonical way to solve this to take object locks?

Sure. That's where things in lmgr.c come into play, like
LockSharedObject(), and you could hold with an exclusive lock on a
given object until the end of a transaction before opening the catalog
relation with heap_open(), however with those you need to know the
object OID before taking a lock on the parent relation, right? So you
face problems with lock upgrades, or race conditions show up more
easily. I have to admit that I have not dug much into the problem yet,
it is easy enough to have isolation tests by the way, and I just
noticed that ALTER DATABASE SET can equally trigger the error.
-- 
Michael


pgsql-hackers by date:

Previous
From: Hannu Krosing
Date:
Subject: Re: AS OF queries
Next
From: Timo Myyrä
Date:
Subject: Re: Oracle to postgres migration