Horton

Re: Concurrent ALTER SEQUENCE RESTART Regression

Peter Eisentraut <peter.eisentraut@2ndquadrant.com>

View thread View on postgr.es
From: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
To: Michael Paquier <michael.paquier@gmail.com>, Jason Petersen <jason@citusdata.com>
Cc: PostgreSQL mailing lists <pgsql-bugs@postgresql.org>
Date: 2017-04-25T19:17:39Z
Lists: pgsql-bugs, pgsql-hackers 
On 4/25/17 00:26, Michael Paquier wrote:
> So things are broken for sequences since commit 1753b1b0 (adding Peter
> in CC) that has changed the way sequence metadata is handled. The
> failure happens in CatalogTupleUpdate() which uses
> simple_heap_update() that caller can only use if updates are
> concurrent safe. But since 1753b1b0 that is not true as the sequence
> is locked with AccessShareLock.

I think you are confusing locking the sequence versus locking the
pg_sequence catalog.  The error is coming from CatalogTupleUpdate() on
pg_sequence, which is locked using RowExclusiveLock, which is what we
use for most DDL commands doing catalog changes.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Commits

  1. Make ALTER SEQUENCE, including RESTART, fully transactional.

  2. Modify sequence catalog tuple before invoking post alter hook.

  3. Use weaker locks when updating pg_subscription_rel

  4. Add pg_sequence system catalog

  5. Modify sequence state storage to eliminate dangling-pointer problem