postgresql/src
Heikki Linnakangas 8cfb174a61 Set next multixid's offset when creating a new multixid
With this commit, the next multixid's offset will always be set on the
offsets page, by the time that a backend might try to read it, so we
no longer need the waiting mechanism with the condition variable. In
other words, this eliminates "corner case 2" mentioned in the
comments.

The waiting mechanism was broken in a few scenarios:

- When nextMulti was advanced without WAL-logging the next
  multixid. For example, if a later multixid was already assigned and
  WAL-logged before the previous one was WAL-logged, and then the
  server crashed. In that case the next offset would never be set in
  the offsets SLRU, and a query trying to read it would get stuck
  waiting for it. Same thing could happen if pg_resetwal was used to
  forcibly advance nextMulti.

- In hot standby mode, a deadlock could happen where one backend waits
  for the next multixid assignment record, but WAL replay is not
  advancing because of a recovery conflict with the waiting backend.

The old TAP test used carefully placed injection points to exercise
the old waiting code, but now that the waiting code is gone, much of
the old test is no longer relevant. Rewrite the test to reproduce the
IPC/MultixactCreation hang after crash recovery instead, and to verify
that previously recorded multixids stay readable.

Backpatch to all supported versions. In back-branches, we still need
to be able to read WAL that was generated before this fix, so in the
back-branches this includes a hack to initialize the next offsets page
when replaying XLOG_MULTIXACT_CREATE_ID for the last multixid on a
page. On 'master', bump XLOG_PAGE_MAGIC instead to indicate that the
WAL is not compatible.

Author: Andrey Borodin <amborodin@acm.org>
Reviewed-by: Dmitry Yurichev <dsy.075@yandex.ru>
Reviewed-by: Álvaro Herrera <alvherre@kurilemu.de>
Reviewed-by: Kirill Reshke <reshkekirill@gmail.com>
Reviewed-by: Ivan Bykov <i.bykov@modernsys.ru>
Reviewed-by: Chao Li <li.evan.chao@gmail.com>
Discussion: https://www.postgresql.org/message-id/172e5723-d65f-4eec-b512-14beacb326ce@yandex.ru
Backpatch-through: 14
2025-12-03 19:15:26 +02:00
..
backend Set next multixid's offset when creating a new multixid 2025-12-03 19:15:26 +02:00
bin Print new OldestXID value in pg_resetwal when it's being changed 2025-11-19 18:06:26 +02:00
common With GB18030, prevent SIGSEGV from reading past end of allocation. 2025-05-05 04:52:08 -07:00
fe_utils In fmtIdEnc(), handle failure of enlargePQExpBuffer(). 2025-02-16 12:46:35 -05:00
include Fix incorrect IndexOptInfo header comment 2025-11-24 17:02:00 +13:00
interfaces libpq: Prevent some overflows of int/size_t 2025-11-10 06:03:05 -08:00
makefiles Refactor DLSUFFIX handling 2022-03-25 08:56:02 +01:00
pl Translation updates 2025-11-10 13:05:20 +01:00
port Fix POSIX compliance in pgwin32_unsetenv() for "name" argument 2025-10-21 08:08:40 +09:00
template On NetBSD, force dynamic symbol resolution at postmaster start. 2022-08-30 17:28:55 -04:00
test Avoid rewriting data-modifying CTEs more than once. 2025-11-29 12:33:35 +00:00
timezone Update time zone data files to tzdata release 2025b. 2025-04-30 11:14:10 -04:00
tools ci: Per-repo configuration for manually trigger tasks 2025-08-14 11:33:51 -04:00
tutorial Doc: sync src/tutorial/basics.source with SGML documentation. 2022-11-19 13:09:14 -05:00
.gitignore
DEVELOPERS
Makefile
Makefile.global.in Don't put library-supplied -L/-I switches before user-supplied ones. 2025-07-29 15:17:41 -04:00
Makefile.shlib Stop using "-multiply_defined suppress" on macOS. 2023-09-26 21:06:21 -04:00
nls-global.mk Fix update-po for the PGXS case 2025-10-16 20:21:05 +02:00