Re: [HACKERS] [BUGS] Concurrent ALTER SEQUENCE RESTART Regression - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] [BUGS] Concurrent ALTER SEQUENCE RESTART Regression
Date
Msg-id 2913.1494426542@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] [BUGS] Concurrent ALTER SEQUENCE RESTART Regression  (Petr Jelinek <petr.jelinek@2ndquadrant.com>)
Responses Re: [HACKERS] [BUGS] Concurrent ALTER SEQUENCE RESTART Regression  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
Petr Jelinek <petr.jelinek@2ndquadrant.com> writes:
> On 10/05/17 07:09, Peter Eisentraut wrote:
>> I think the correct fix is to have nextval() and ALTER SEQUENCE use
>> sensible lock levels so that they block each other.  Since
>> nextval() currently uses AccessShareLock, the suggestion was for
>> ALTER SEQUENCE to therefore use AccessExclusiveLock.  But I think a
>> better idea would be for nextval() to use RowExclusiveLock
>> (analogous to UPDATE) and ALTER SEQUENCE to use
>> ShareRowExclusiveLock, which would also satisfy issue #1.

> When I proposed this upstream, Andres raised concern about performance
> of nextval() if we do this, did you try to run any benchmark on this?

As long as it doesn't block, the change in lock strength doesn't actually
make any speed difference does it?

If we were taking AccessExclusiveLock somewhere, I'd be worried about
the cost of WAL-logging those; but this proposal does not include any.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Petr Jelinek
Date:
Subject: Re: [HACKERS] 'nocopy data' option is set in SUBSCRIPTION but stilldata is getting migrated
Next
From: Chapman Flack
Date:
Subject: Re: [HACKERS] idea: custom log_line_prefix components besidesapplication_name