Re: Concurrent ALTER SEQUENCE RESTART Regression
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Michael Paquier <michael.paquier@gmail.com>
Cc: Andres Freund <andres@anarazel.de>,
Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, Jason Petersen <jason@citusdata.com>,
PostgreSQL mailing lists <pgsql-bugs@postgresql.org>
Date: 2017-05-02T02:10:36Z
Lists: pgsql-bugs, pgsql-hackers
On Wed, Apr 26, 2017 at 9:51 PM, Michael Paquier <michael.paquier@gmail.com> wrote: > On Thu, Apr 27, 2017 at 10:12 AM, Andres Freund <andres@anarazel.de> wrote: >> On 2017-04-26 21:07:20 -0400, Peter Eisentraut wrote: >>> One thing we could do, since all catalog updates now go through >>> CatalogTupleUpdate(), is not use simple_heap_update() there but do the >>> heap_update() directly and provide a better user-facing error message. >> >> I think it's unacceptable to regress with an error message here. I've >> seen sequence DDL being used while concurrent DML was onging in a number >> of production use cases, and just starting to error out instead of >> properly blocking doesn't seem acceptable to me. > > +1'ing on this argument. +1 from me, too. The fact that we have some other places where we get "ERROR: tuple concurrently updated" is an awfulness that nobody's gotten around to fixing, not an excuse to regress cases that were previously working properly (never mind the other breakage reported downthread). If this can't be fixed the whole patch should be ripped out, IMHO. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Commits
-
Make ALTER SEQUENCE, including RESTART, fully transactional.
- 3d79013b970d 10.0 landed
-
Modify sequence catalog tuple before invoking post alter hook.
- 665104557fdc 10.0 landed
-
Use weaker locks when updating pg_subscription_rel
- 521fd4795e3e 10.0 cited
-
Add pg_sequence system catalog
- 1753b1b02703 10.0 cited
-
Modify sequence state storage to eliminate dangling-pointer problem
- a2597ef17958 7.3.1 cited