Concurrent ALTER SEQUENCE RESTART Regression

Jason Petersen <jason@citusdata.com>

From: Jason Petersen <jason@citusdata.com>
To: pgsql-bugs@postgresql.org
Date: 2017-04-24T19:52:33Z
Lists: pgsql-bugs, pgsql-hackers
I recently found a behavior regression for ALTER SEQUENCE.

Repro. Steps
============

  1. Create a new sequence: CREATE SEQUENCE my_seq;
  2. Start this loop twice in different shells:
       while true; do psql -1Xtc 'ALTER SEQUENCE my_seq RESTART 1'; done

Expected (pre-10) Behavior
==========================

Each loop should repeatedly succeed and simply print ALTER SEQUENCE over and over.

Actual (PG 10) Behavior
=======================

The output stream is punctuated by occasional "ERROR:  tuple concurrently updated" messages.

Summary
=======

While I understand the above workload is nonsensical, given the non-transactional behavior of ALTER SEQUENCE statements, previous PostgreSQL versions did not produce an error. It is likely applications have been coded with that assumption and will not deal well with the new behavior.

Having poked around the code a bit, I see the functions to access for sequence state have changed; I’m assuming this is an unintended side-effect of that change.

I haven’t worked up a patch myself, but I have some hope someone more familiar with the underlying changes could make quick work of this.

--
Jason Petersen
Software Engineer | Citus Data
303.736.9255
jason@citusdata.com

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