From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org, Postgres hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Getting rid of "tuple concurrently updated" elog()s with concurrent DDLs (at least ALTER TABLE) |
Date: | 2017-12-26 12:14:06 |
Message-ID: | CAB7nPqSZCkVfibTvx9TYmHYhVtV_vOMNwOpLHnRU85qeiimUaQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Dec 26, 2017 at 4:30 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> You're proposing to lock the entire relation against many forms of concurrent DDL, just to get rid of that error? That seems 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
From | Date | Subject | |
---|---|---|---|
Next Message | Petr Jelinek | 2017-12-26 13:03:22 | Re: BUGFIX: standby disconnect can corrupt serialized reorder buffers |
Previous Message | Hannu Krosing | 2017-12-26 12:11:18 | Re: AS OF queries |