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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
