pgsql: Don't reset 'latest_page_number' when replaying multixid truncat - Mailing list pgsql-committers

From Heikki Linnakangas
Subject pgsql: Don't reset 'latest_page_number' when replaying multixid truncat
Date
Msg-id E1w4Hvk-000vzD-3A@gemulon.postgresql.org
Whole thread Raw
List pgsql-committers
Don't reset 'latest_page_number' when replaying multixid truncation

'latest_page_number' is set to the correct value, according to
nextOffset, early at system startup. Contrary to the comment, it hence
should be set up correctly by the time we get to WAL replay.

This was committed to back-branches earlier already (commit
817f74600d), to fix a bug in a backwards-compatibility codepath. We
don't have that bug on 'master', but the change nevertheless makes
sense on 'master' too.

Reviewed-by: Andrey Borodin <x4mmm@yandex-team.ru>
Reviewed-by: Kirill Reshke <reshkekirill@gmail.com>
Discussion: https://www.postgresql.org/message-id/20260214090150.GC2297@p46.dedyn.io;lightning.p46.dedyn.io
Discussion: https://www.postgresql.org/message-id/e1787b17-dc93-4621-a5a1-c713d1ac6a1b@iki.fi

Branch
------
master

Details
-------
https://git.postgresql.org/pg/commitdiff/516310ed4dba89bd300242df0d56b4782f33ed4d

Modified Files
--------------
src/backend/access/transam/multixact.c | 10 ----------
1 file changed, 10 deletions(-)


pgsql-committers by date:

Previous
From: Michael Paquier
Date:
Subject: pgsql: Add test for single-page VACUUM of hash index on INSERT
Next
From: Melanie Plageman
Date:
Subject: pgsql: Detect and fix visibility map corruption in more cases