Re: Getting rid of "tuple concurrently updated" elog()s withconcurrent DDLs (at least ALTER TABLE)
От | Michael Paquier |
---|---|
Тема | Re: Getting rid of "tuple concurrently updated" elog()s withconcurrent DDLs (at least ALTER TABLE) |
Дата | |
Msg-id | CAB7nPqSZCkVfibTvx9TYmHYhVtV_vOMNwOpLHnRU85qeiimUaQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Getting rid of "tuple concurrently updated" elog()s with concurrent DDLs (at least ALTER TABLE) (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: Getting rid of "tuple concurrently updated" elog()s withconcurrent DDLs (at least ALTER TABLE)
|
Список | 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 по дате отправления: