pg.ddx.io pgsql-committers@postgresql.org mailing list archivehelp / color / mirror / Atom feed
pgsql: Fix relcache reference leak when decoding TRUNCATE 7+ messages / 1 participants [nested] [flat]
* pgsql: Fix relcache reference leak when decoding TRUNCATE @ 2026-08-19 02:33 Michael Paquier <michael@paquier.xyz> 0 siblings, 0 replies; 7+ messages in thread From: Michael Paquier @ 2026-08-19 02:33 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix relcache reference leak when decoding TRUNCATE ReorderBufferProcessTXN() opens every relation referenced by a TRUNCATE change. When RelationIsLogicallyLogged() returns false, it skips the relation without releasing the reference acquired by RelationIdGetRelation(). Looking at the in-core code paths building XLOG_HEAP_TRUNCATE records, no relation OIDs would be included if they do not satisfy RelationIsLogicallyLogged(). One pattern that could go through is if a table is switched to SET UNLOGGED, but that would not be reachable in practice as the decoding happens after a historical snapshot is taken, so the relation should still be valid. This is a defense-in-depth measure in practice, and we tend to be careful about how Relations are handled when sending changes to output plugins, so backpatch all the way down. Author: Chao Li <li.evan.chao@gmail.com> Reviewed-by: Xuneng Zhou <xunengzhou@gmail.com> Discussion: https://postgr.es/m/7DD65D03-3B5A-43B2-99AD-8E6AF5372BAB@gmail.com Backpatch-through: 14 Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/bdbf662b1b93911d47a7a97c2dfb5f992bb255ae Modified Files -------------- src/backend/replication/logical/reorderbuffer.c | 3 +++ 1 file changed, 3 insertions(+) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Fix relcache reference leak when decoding TRUNCATE @ 2026-08-19 02:33 Michael Paquier <michael@paquier.xyz> 0 siblings, 0 replies; 7+ messages in thread From: Michael Paquier @ 2026-08-19 02:33 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix relcache reference leak when decoding TRUNCATE ReorderBufferProcessTXN() opens every relation referenced by a TRUNCATE change. When RelationIsLogicallyLogged() returns false, it skips the relation without releasing the reference acquired by RelationIdGetRelation(). Looking at the in-core code paths building XLOG_HEAP_TRUNCATE records, no relation OIDs would be included if they do not satisfy RelationIsLogicallyLogged(). One pattern that could go through is if a table is switched to SET UNLOGGED, but that would not be reachable in practice as the decoding happens after a historical snapshot is taken, so the relation should still be valid. This is a defense-in-depth measure in practice, and we tend to be careful about how Relations are handled when sending changes to output plugins, so backpatch all the way down. Author: Chao Li <li.evan.chao@gmail.com> Reviewed-by: Xuneng Zhou <xunengzhou@gmail.com> Discussion: https://postgr.es/m/7DD65D03-3B5A-43B2-99AD-8E6AF5372BAB@gmail.com Backpatch-through: 14 Branch ------ REL_19_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/4a710d68871cd9bbdcc57b244dbbeeca08de7735 Modified Files -------------- src/backend/replication/logical/reorderbuffer.c | 3 +++ 1 file changed, 3 insertions(+) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Fix relcache reference leak when decoding TRUNCATE @ 2026-08-19 02:33 Michael Paquier <michael@paquier.xyz> 0 siblings, 0 replies; 7+ messages in thread From: Michael Paquier @ 2026-08-19 02:33 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix relcache reference leak when decoding TRUNCATE ReorderBufferProcessTXN() opens every relation referenced by a TRUNCATE change. When RelationIsLogicallyLogged() returns false, it skips the relation without releasing the reference acquired by RelationIdGetRelation(). Looking at the in-core code paths building XLOG_HEAP_TRUNCATE records, no relation OIDs would be included if they do not satisfy RelationIsLogicallyLogged(). One pattern that could go through is if a table is switched to SET UNLOGGED, but that would not be reachable in practice as the decoding happens after a historical snapshot is taken, so the relation should still be valid. This is a defense-in-depth measure in practice, and we tend to be careful about how Relations are handled when sending changes to output plugins, so backpatch all the way down. Author: Chao Li <li.evan.chao@gmail.com> Reviewed-by: Xuneng Zhou <xunengzhou@gmail.com> Discussion: https://postgr.es/m/7DD65D03-3B5A-43B2-99AD-8E6AF5372BAB@gmail.com Backpatch-through: 14 Branch ------ REL_18_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/ecf2492b44545dd2cf0bf6411bf3bdbb6a5b5f22 Modified Files -------------- src/backend/replication/logical/reorderbuffer.c | 3 +++ 1 file changed, 3 insertions(+) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Fix relcache reference leak when decoding TRUNCATE @ 2026-08-19 02:33 Michael Paquier <michael@paquier.xyz> 0 siblings, 0 replies; 7+ messages in thread From: Michael Paquier @ 2026-08-19 02:33 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix relcache reference leak when decoding TRUNCATE ReorderBufferProcessTXN() opens every relation referenced by a TRUNCATE change. When RelationIsLogicallyLogged() returns false, it skips the relation without releasing the reference acquired by RelationIdGetRelation(). Looking at the in-core code paths building XLOG_HEAP_TRUNCATE records, no relation OIDs would be included if they do not satisfy RelationIsLogicallyLogged(). One pattern that could go through is if a table is switched to SET UNLOGGED, but that would not be reachable in practice as the decoding happens after a historical snapshot is taken, so the relation should still be valid. This is a defense-in-depth measure in practice, and we tend to be careful about how Relations are handled when sending changes to output plugins, so backpatch all the way down. Author: Chao Li <li.evan.chao@gmail.com> Reviewed-by: Xuneng Zhou <xunengzhou@gmail.com> Discussion: https://postgr.es/m/7DD65D03-3B5A-43B2-99AD-8E6AF5372BAB@gmail.com Backpatch-through: 14 Branch ------ REL_17_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/26a9d8ea643520856ca558b926970e70fcbbf6dc Modified Files -------------- src/backend/replication/logical/reorderbuffer.c | 3 +++ 1 file changed, 3 insertions(+) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Fix relcache reference leak when decoding TRUNCATE @ 2026-08-19 02:33 Michael Paquier <michael@paquier.xyz> 0 siblings, 0 replies; 7+ messages in thread From: Michael Paquier @ 2026-08-19 02:33 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix relcache reference leak when decoding TRUNCATE ReorderBufferProcessTXN() opens every relation referenced by a TRUNCATE change. When RelationIsLogicallyLogged() returns false, it skips the relation without releasing the reference acquired by RelationIdGetRelation(). Looking at the in-core code paths building XLOG_HEAP_TRUNCATE records, no relation OIDs would be included if they do not satisfy RelationIsLogicallyLogged(). One pattern that could go through is if a table is switched to SET UNLOGGED, but that would not be reachable in practice as the decoding happens after a historical snapshot is taken, so the relation should still be valid. This is a defense-in-depth measure in practice, and we tend to be careful about how Relations are handled when sending changes to output plugins, so backpatch all the way down. Author: Chao Li <li.evan.chao@gmail.com> Reviewed-by: Xuneng Zhou <xunengzhou@gmail.com> Discussion: https://postgr.es/m/7DD65D03-3B5A-43B2-99AD-8E6AF5372BAB@gmail.com Backpatch-through: 14 Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/e8d079313a0b5f45e2e382ca77572fc780cad0ba Modified Files -------------- src/backend/replication/logical/reorderbuffer.c | 3 +++ 1 file changed, 3 insertions(+) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Fix relcache reference leak when decoding TRUNCATE @ 2026-08-19 02:33 Michael Paquier <michael@paquier.xyz> 0 siblings, 0 replies; 7+ messages in thread From: Michael Paquier @ 2026-08-19 02:33 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix relcache reference leak when decoding TRUNCATE ReorderBufferProcessTXN() opens every relation referenced by a TRUNCATE change. When RelationIsLogicallyLogged() returns false, it skips the relation without releasing the reference acquired by RelationIdGetRelation(). Looking at the in-core code paths building XLOG_HEAP_TRUNCATE records, no relation OIDs would be included if they do not satisfy RelationIsLogicallyLogged(). One pattern that could go through is if a table is switched to SET UNLOGGED, but that would not be reachable in practice as the decoding happens after a historical snapshot is taken, so the relation should still be valid. This is a defense-in-depth measure in practice, and we tend to be careful about how Relations are handled when sending changes to output plugins, so backpatch all the way down. Author: Chao Li <li.evan.chao@gmail.com> Reviewed-by: Xuneng Zhou <xunengzhou@gmail.com> Discussion: https://postgr.es/m/7DD65D03-3B5A-43B2-99AD-8E6AF5372BAB@gmail.com Backpatch-through: 14 Branch ------ REL_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/402e9624444b3b3c3f75c90d3b3d847dcfa1b8f9 Modified Files -------------- src/backend/replication/logical/reorderbuffer.c | 3 +++ 1 file changed, 3 insertions(+) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Fix relcache reference leak when decoding TRUNCATE @ 2026-08-19 02:33 Michael Paquier <michael@paquier.xyz> 0 siblings, 0 replies; 7+ messages in thread From: Michael Paquier @ 2026-08-19 02:33 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix relcache reference leak when decoding TRUNCATE ReorderBufferProcessTXN() opens every relation referenced by a TRUNCATE change. When RelationIsLogicallyLogged() returns false, it skips the relation without releasing the reference acquired by RelationIdGetRelation(). Looking at the in-core code paths building XLOG_HEAP_TRUNCATE records, no relation OIDs would be included if they do not satisfy RelationIsLogicallyLogged(). One pattern that could go through is if a table is switched to SET UNLOGGED, but that would not be reachable in practice as the decoding happens after a historical snapshot is taken, so the relation should still be valid. This is a defense-in-depth measure in practice, and we tend to be careful about how Relations are handled when sending changes to output plugins, so backpatch all the way down. Author: Chao Li <li.evan.chao@gmail.com> Reviewed-by: Xuneng Zhou <xunengzhou@gmail.com> Discussion: https://postgr.es/m/7DD65D03-3B5A-43B2-99AD-8E6AF5372BAB@gmail.com Backpatch-through: 14 Branch ------ REL_14_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/29b52d2b47fb8fa892695bc941d3e035164481cf Modified Files -------------- src/backend/replication/logical/reorderbuffer.c | 3 +++ 1 file changed, 3 insertions(+) ^ permalink raw reply [nested|flat] 7+ messages in thread
end of thread, other threads:[~2026-08-19 02:33 UTC | newest] Thread overview: 7+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2026-08-19 02:33 pgsql: Fix relcache reference leak when decoding TRUNCATE Michael Paquier <michael@paquier.xyz> 2026-08-19 02:33 pgsql: Fix relcache reference leak when decoding TRUNCATE Michael Paquier <michael@paquier.xyz> 2026-08-19 02:33 pgsql: Fix relcache reference leak when decoding TRUNCATE Michael Paquier <michael@paquier.xyz> 2026-08-19 02:33 pgsql: Fix relcache reference leak when decoding TRUNCATE Michael Paquier <michael@paquier.xyz> 2026-08-19 02:33 pgsql: Fix relcache reference leak when decoding TRUNCATE Michael Paquier <michael@paquier.xyz> 2026-08-19 02:33 pgsql: Fix relcache reference leak when decoding TRUNCATE Michael Paquier <michael@paquier.xyz> 2026-08-19 02:33 pgsql: Fix relcache reference leak when decoding TRUNCATE Michael Paquier <michael@paquier.xyz>
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