Re: [HACKERS] Concurrent ALTER SEQUENCE RESTART Regression

From: Andres Freund <andres(at)anarazel(dot)de>
To: Robert Haas <robertmhaas(at)gmail(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Noah Misch <noah(at)leadboat(dot)com>, Jason Petersen <jason(at)citusdata(dot)com>, PostgreSQL mailing lists <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: [HACKERS] Concurrent ALTER SEQUENCE RESTART Regression
Date: 2017-06-01 00:07:16
Message-ID: 20170601000716.qxg7c46ukkiljjb3@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

On 2017-05-31 14:24:38 -0700, Andres Freund wrote:
> On 2017-05-24 10:52:37 -0400, Robert Haas wrote:
> > On Wed, May 24, 2017 at 10:32 AM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> > > Well, but then we should just remove minval/maxval if we can't rely on
> > > it.
> >
> > That seems like a drastic overreaction to me.
>
> Well, either they work, or they don't. But since it turns out to be
> easy enough to fix anyway...
>
>
> > > I wonder if that's not actually very little new code, and I think we
> > > might end up regretting having yet another inconsistent set of semantics
> > > in v10, which we'll then end up changing again in v11.
> >
> > I'm not exercised enough about it to spend time on it or to demand
> > that Peter do so, but feel free to propose something.
>
> This turns out to be fairly simple patch. We already do precisely what
> I describe when resetting a sequence for TRUNCATE, so it's an already
> tested codepath. It also follows a lot more established practice around
> transactional schema changes, so I think that's architecturally better
> too. Peter, to my understanding, agreed with that reasoning at pgcon.
>
> I just have two questions:
> 1) We've introduced, in 3d092fe540, infrastructure to avoid unnecessary
> catalog updates, in an attemt to fix the "concurrently updated"
> error. But that turned out to not be sufficient anyway, and it bulks
> up the code. I'd vote for just removing that piece of logic, it
> doesn't buy us anything meaningful, and it's bulky.
>
> 2) There's currently logic that takes a lower level lock for ALTER
> SEQUENCE RESET without other options. I think that's a bit confusing
> with the proposed change, because then it's unclear when ALTER
> SEQUENCE is transactional and when not. I think it's actually a lot
> easier to understand if we keep nextval()/setval() as
> non-transactional, and ALTER SEQUENCE as transactional.
>
> Comments?

Here's a patch doing what I suggested above. The second patch addresses
an independent oversight where the post alter hook was invoked before
doing the catalog update.

- Andres

Attachment Content-Type Size
0001-Make-ALTER-SEQUENCE-including-RESTART-fully-transact.patch text/x-patch 17.3 KB
0002-Modify-sequence-catalog-tuple-before-invoking-post-a.patch text/x-patch 1.2 KB

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message fte 2017-06-01 06:59:59 BUG #14682: row level security not work with partitioned table
Previous Message David G. Johnston 2017-05-31 22:49:10 Re: BUG #14681: Erroneous modulo (%) result

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2017-06-01 00:15:15 tap tests on older branches fail if concurrency is used
Previous Message Neha Khatri 2017-05-31 23:59:25 Typo in xlogfuncs.c [WAS Re: Incorrect mention of pg_xlog_switch() in xlogfuncs.c]