database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-10-18 04:29:09 +03:00
Code Activity

Make ALTER SEQUENCE, including RESTART, fully transactional.

Browse Source 
Previously the changes to the "data" part of the sequence, i.e. the
one containing the current value, were not transactional, whereas the
definition, including minimum and maximum value were.  That leads to
odd behaviour if a schema change is rolled back, with the potential
that out-of-bound sequence values can be returned.

To avoid the issue create a new relfilenode fork whenever ALTER
SEQUENCE is executed, similar to how TRUNCATE ... RESTART IDENTITY
already is already handled.

This commit also makes ALTER SEQUENCE RESTART transactional, as it
seems to be too confusing to have some forms of ALTER SEQUENCE behave
transactionally, some forms not.  This way setval() and nextval() are
not transactional, but DDL is, which seems to make sense.

This commit also rolls back parts of the changes made in 3d092fe540
and f8dc1985f as they're now not needed anymore.

Author: Andres Freund
Discussion: https://postgr.es/m/20170522154227.nvafbsm62sjpbxvd@alap3.anarazel.de
Backpatch: Bug is in master/v10 only
This commit is contained in:
Andres Freund
2017-05-31 16:39:27 -07:00
parent e9a3c047a5
commit 3d79013b97
4 changed files with 96 additions and 153 deletions
Download Patch File Download Diff File Expand all files Collapse all files

19
src/test/isolation/specs/sequence-ddl.spec
View File

@@ -15,6 +15,7 @@ setup { BEGIN; }
step "s1alter" { ALTER SEQUENCE seq1 MAXVALUE 10; }
step "s1alter2" { ALTER SEQUENCE seq1 MAXVALUE 20; }
step "s1restart" { ALTER SEQUENCE seq1 RESTART WITH 5; }
step "s1setval" { SELECT setval('seq1', 5); }
step "s1commit" { COMMIT; }
session "s2"
@@ -24,16 +25,18 @@ step "s2commit" { COMMIT; }
permutation "s1alter" "s1commit" "s2nv"
# Prior to PG10, the s2nv would see the uncommitted s1alter change,
# but now it waits.
# Prior to PG10, the s2nv step would see the uncommitted s1alter
# change, but now it waits.
permutation "s1alter" "s2nv" "s1commit"
# Prior to PG10, the s2nv step would see the uncommitted s1reset
# change, but now it waits.
permutation "s1restart" "s2nv" "s1commit"
# In contrast to ALTER setval() is non-transactional, so it doesn't
# have to wait.
permutation "s1restart" "s2nv" "s1commit"
# nextval doesn't release lock until transaction end, so s1alter2 has
# to wait for s2commit.
permutation "s2begin" "s2nv" "s1alter2" "s2commit" "s1commit"
# RESTART is nontransactional, so s2nv sees it right away
permutation "s1restart" "s2nv" "s1commit"
# RESTART does not wait
permutation "s2begin" "s2nv" "s1restart" "s2commit" "s1commit"