Re: [HACKERS] [BUGS] Concurrent ALTER SEQUENCE RESTART Regression

On 10/05/17 07:09, Peter Eisentraut wrote:
> On 5/7/17 19:43, Andres Freund wrote:
>> 3. Keep the catalog, make ALTER properly transactional, blocking
>>    concurrent nextval()s. This resolves the issue that nextval() can't
>>    see the changed definition of the sequence.
> 
> This was the intended choice.
> 
> [...]
> 
> 5. nextval() disregarding uncommitted ALTER SEQUENCE changes.  In
>    <PG10, it would read the uncommitted metadata and observe it.
>    Currently, it goes ahead even if there is an uncommitted ALTER
>    SEQUENCE pending that would prohibit what it's about to do (e.g.,
>    MAXVALUE change).
> 
>    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?

Looking at the changes to open_share_lock(), I wonder if we need to have
lock level as parameter so that lastval() is not blocked.

--  Petr Jelinek                  http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training &
Services