pg.ddx.io pgsql-committers@postgresql.org mailing list archivehelp / color / mirror / Atom feed
pgsql: Add check for invalid offset at multixid truncation 6+ messages / 1 participants [nested] [flat]
* pgsql: Add check for invalid offset at multixid truncation @ 2026-01-15 15:03 Heikki Linnakangas <heikki.linnakangas@iki.fi> 0 siblings, 0 replies; 6+ messages in thread From: Heikki Linnakangas @ 2026-01-15 15:03 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/102bdaa9be13e65de898991f69ddeea517789fb3 Modified Files -------------- src/backend/access/transam/multixact.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Add check for invalid offset at multixid truncation @ 2026-01-15 15:03 Heikki Linnakangas <heikki.linnakangas@iki.fi> 0 siblings, 0 replies; 6+ messages in thread From: Heikki Linnakangas @ 2026-01-15 15:03 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 Branch ------ REL_18_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/09532a78b8c6b49b5176bc1cd4671c571520a8c8 Modified Files -------------- src/backend/access/transam/multixact.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Add check for invalid offset at multixid truncation @ 2026-01-15 15:03 Heikki Linnakangas <heikki.linnakangas@iki.fi> 0 siblings, 0 replies; 6+ messages in thread From: Heikki Linnakangas @ 2026-01-15 15:03 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 Branch ------ REL_17_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/d3ad4cef6ea90cc0be02ccee8fa8b3bd961c9c33 Modified Files -------------- src/backend/access/transam/multixact.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Add check for invalid offset at multixid truncation @ 2026-01-15 15:03 Heikki Linnakangas <heikki.linnakangas@iki.fi> 0 siblings, 0 replies; 6+ messages in thread From: Heikki Linnakangas @ 2026-01-15 15:03 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/c7946e6f32c9a503512fae3ed0575581b49e8680 Modified Files -------------- src/backend/access/transam/multixact.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Add check for invalid offset at multixid truncation @ 2026-01-15 15:03 Heikki Linnakangas <heikki.linnakangas@iki.fi> 0 siblings, 0 replies; 6+ messages in thread From: Heikki Linnakangas @ 2026-01-15 15:03 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 Branch ------ REL_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/a563ac619407984319c4d4d59c919e7a170087ca Modified Files -------------- src/backend/access/transam/multixact.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Add check for invalid offset at multixid truncation @ 2026-01-15 15:03 Heikki Linnakangas <heikki.linnakangas@iki.fi> 0 siblings, 0 replies; 6+ messages in thread From: Heikki Linnakangas @ 2026-01-15 15:03 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 Branch ------ REL_14_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/46be454ca4131e9731577d392897803d951e71c8 Modified Files -------------- src/backend/access/transam/multixact.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) ^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2026-01-15 15:03 UTC | newest] Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2026-01-15 15:03 pgsql: Add check for invalid offset at multixid truncation Heikki Linnakangas <heikki.linnakangas@iki.fi> 2026-01-15 15:03 pgsql: Add check for invalid offset at multixid truncation Heikki Linnakangas <heikki.linnakangas@iki.fi> 2026-01-15 15:03 pgsql: Add check for invalid offset at multixid truncation Heikki Linnakangas <heikki.linnakangas@iki.fi> 2026-01-15 15:03 pgsql: Add check for invalid offset at multixid truncation Heikki Linnakangas <heikki.linnakangas@iki.fi> 2026-01-15 15:03 pgsql: Add check for invalid offset at multixid truncation Heikki Linnakangas <heikki.linnakangas@iki.fi> 2026-01-15 15:03 pgsql: Add check for invalid offset at multixid truncation Heikki Linnakangas <heikki.linnakangas@iki.fi>
This inbox is served by DDX for PostgreSQL; see mirroring instructions for how to clone and mirror all data and code used for this inbox