Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Commitaf026b5

Browse files
committed
Fix longstanding crash-safety bug with newly-created-or-reset sequences.
If a crash occurred immediately after the first nextval() call for a serialcolumn, WAL replay would restore the sequence to a state in which itappeared that no nextval() had been done, thus allowing the first sequencevalue to be returned again by the next nextval() call; as reported inbug #6748 from Xiangming Mei.More generally, the problem would occur if an ALTER SEQUENCE was executedon a freshly created or reset sequence. (The manifestation with serialcolumns was introduced in 8.2 when we added an ALTER SEQUENCE OWNED BY stepto serial column creation.) The cause is that sequence creation attemptedto save one WAL entry by writing out a WAL record that made it appear thatthe first nextval() had already happened (viz, with is_called = true),while marking the sequence's in-database state with log_cnt = 1 to showthat the first nextval() need not emit a WAL record. However, ALTERSEQUENCE would emit a new WAL entry reflecting the actual in-database state(with is_called = false). Then, nextval would allocate the first sequencevalue and set is_called = true, but it would trust the log_cnt value andnot emit any WAL record. A crash at this point would thus restore thesequence to its post-ALTER state, causing the next nextval() call to returnthe first sequence value again.To fix, get rid of the idea of logging an is_called status different fromreality. This means that the first nextval-driven WAL record will happenat the first nextval call not the second, but the marginal cost of that ispretty negligible. In addition, make sure that ALTER SEQUENCE resetslog_cnt to zero in any case where it touches sequence parameters thataffect future nextval results. This will result in some user-visiblechanges in the contents of a sequence's log_cnt column, as reflected in thepatch's regression test changes; but no application should be depending onthat anyway, since it was already true that log_cnt changes ratherunpredictably depending on checkpoint timing.In addition, make some basically-cosmetic improvements to get rid ofsequence.c's undesirable intimacy with page layout details. It was alwaysreally trying to WAL-log the contents of the sequence tuple, so we shouldhave it do that directly using a HeapTuple's t_data and t_len, rather thanbacking into it with some magic assumptions about where the tuple would beon the sequence's page.Back-patch to all supported branches.
1 parent08d715a commitaf026b5

File tree

3 files changed

+102
-74
lines changed

3 files changed

+102
-74
lines changed

0 commit comments

Comments
 (0)

[8]ページ先頭

©2009-2025 Movatter.jp