postgres.git / summary / log / commit / refs

commit    d3ad4cef6ea90cc0be02ccee8fa8b3bd961c9c33
Author:   Heikki Linnakangas <heikki.linnakangas@iki.fi>
Date:     Thu Jan 15 14:48:45 2026 +0000
First released in: 14.21, 15.16, 16.12, 17.8, 18.2

    Add check for invalid offset at multixid truncation
    
    If a multixid with zero offset is left behind after a crash, and that
    multixid later becomes the oldest multixid, truncation might try to
    look up its offset and read the zero value. In the worst case, we
    might incorrectly use the zero offset to truncate valid SLRU segments
    that are still needed. I'm not sure if that can happen in practice, or
    if there are some other lower-level safeguards or incidental reasons
    that prevent the caller from passing an unwritten multixid as the
    oldest multi. But better safe than sorry, so let's add an explicit
    check for it.
    
    In stable branches, we should perhaps do the same check for
    'oldestOffset', i.e. the offset of the old oldest multixid (in master,
    'oldestOffset' is gone). But if the old oldest multixid has an invalid
    offset, the damage has been done already, and we would never advance
    past that point. It's not clear what we should do in that case. The
    check that this commit adds will prevent such an multixid with invalid
    offset from becoming the oldest multixid in the first place, which
    seems enough for now.
    
    Reviewed-by: Andrey Borodin <x4mmm@yandex-team.ru>
    Discussion: Discussion: https://www.postgresql.org/message-id/000301b2-5b81-4938-bdac-90f6eb660843@iki.fi
    Backpatch-through: 14


 src/backend/access/transam/multixact.c | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 80f93a71b64..c863e4e0556 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -3273,6 +3273,23 @@ TruncateMultiXact(MultiXactId newOldestMulti, Oid newOldestMultiDB)
 		return;
 	}
 
+	/*
+	 * On crash, MultiXactIdCreateFromMembers() can leave behind multixids
+	 * that were not yet written out and hence have zero offset on disk. If
+	 * such a multixid becomes oldestMulti, we won't be able to look up its
+	 * offset. That should be rare, so we don't try to do anything smart about
+	 * it. Just skip the truncation, and hope that by the next truncation
+	 * attempt, oldestMulti has advanced to a valid multixid.
+	 */
+	if (newOldestOffset == 0)
+	{
+		ereport(LOG,
+				(errmsg("cannot truncate up to MultiXact %u because it has invalid offset, skipping truncation",
+						newOldestMulti)));
+		LWLockRelease(MultiXactTruncationLock);
+		return;
+	}
+
 	elog(DEBUG1, "performing multixact truncation: "
 		 "offsets [%u, %u), offsets segments [%llx, %llx), "
 		 "members [%u, %u), members segments [%llx, %llx)",


[parent: a244e1707730]