pg.ddx.io pgsql-committers@postgresql.org mailing list archivehelp / color / mirror / Atom feed
pgsql: Fix a possibility of logical replication slot's restart_lsn goin 6+ messages / 1 participants [nested] [flat]
* pgsql: Fix a possibility of logical replication slot's restart_lsn goin @ 2024-11-16 01:07 Masahiko Sawada <msawada@postgresql.org> 0 siblings, 0 replies; 6+ messages in thread From: Masahiko Sawada @ 2024-11-16 01:07 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix a possibility of logical replication slot's restart_lsn going backwards. Previously LogicalIncreaseRestartDecodingForSlot() accidentally accepted any LSN as the candidate_lsn and candidate_valid after the restart_lsn of the replication slot was updated, so it potentially caused the restart_lsn to move backwards. A scenario where this could happen in logical replication is: after a logical replication restart, based on previous candidate_lsn and candidate_valid values in memory, the restart_lsn advances upon receiving a subscriber acknowledgment. Then, logical decoding restarts from an older point, setting candidate_lsn and candidate_valid based on an old RUNNING_XACTS record. Subsequent subscriber acknowledgments then update the restart_lsn to an LSN older than the current value. In the reported case, after WAL files were removed by a checkpoint, the retreated restart_lsn prevented logical replication from restarting due to missing WAL segments. This change essentially modifies the 'if' condition to 'else if' condition within the function. The previous code had an asymmetry in this regard compared to LogicalIncreaseXminForSlot(), which does almost the same thing for different fields. The WAL removal issue was reported by Hubert Depesz Lubaczewski. Backpatch to all supported versions, since the bug exists since 9.4 where logical decoding was introduced. Reviewed-by: Tomas Vondra, Ashutosh Bapat, Amit Kapila Discussion: https://postgr.es/m/Yz2hivgyjS1RfMKs%40depesz.com Discussion: https://postgr.es/m/85fff40e-148b-4e86-b921-b4b846289132%40vondra.me Backpatch-through: 13 Branch ------ REL_13_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/15dc1abb17ddb4bba3025302d0b71b9325258601 Modified Files -------------- src/backend/replication/logical/logical.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix a possibility of logical replication slot's restart_lsn goin @ 2024-11-16 01:07 Masahiko Sawada <msawada@postgresql.org> 0 siblings, 0 replies; 6+ messages in thread From: Masahiko Sawada @ 2024-11-16 01:07 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix a possibility of logical replication slot's restart_lsn going backwards. Previously LogicalIncreaseRestartDecodingForSlot() accidentally accepted any LSN as the candidate_lsn and candidate_valid after the restart_lsn of the replication slot was updated, so it potentially caused the restart_lsn to move backwards. A scenario where this could happen in logical replication is: after a logical replication restart, based on previous candidate_lsn and candidate_valid values in memory, the restart_lsn advances upon receiving a subscriber acknowledgment. Then, logical decoding restarts from an older point, setting candidate_lsn and candidate_valid based on an old RUNNING_XACTS record. Subsequent subscriber acknowledgments then update the restart_lsn to an LSN older than the current value. In the reported case, after WAL files were removed by a checkpoint, the retreated restart_lsn prevented logical replication from restarting due to missing WAL segments. This change essentially modifies the 'if' condition to 'else if' condition within the function. The previous code had an asymmetry in this regard compared to LogicalIncreaseXminForSlot(), which does almost the same thing for different fields. The WAL removal issue was reported by Hubert Depesz Lubaczewski. Backpatch to all supported versions, since the bug exists since 9.4 where logical decoding was introduced. Reviewed-by: Tomas Vondra, Ashutosh Bapat, Amit Kapila Discussion: https://postgr.es/m/Yz2hivgyjS1RfMKs%40depesz.com Discussion: https://postgr.es/m/85fff40e-148b-4e86-b921-b4b846289132%40vondra.me Backpatch-through: 13 Branch ------ REL_14_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/26c4e896869093f07e9acb982f71bb3c4dae5901 Modified Files -------------- src/backend/replication/logical/logical.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix a possibility of logical replication slot's restart_lsn goin @ 2024-11-16 01:07 Masahiko Sawada <msawada@postgresql.org> 0 siblings, 0 replies; 6+ messages in thread From: Masahiko Sawada @ 2024-11-16 01:07 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix a possibility of logical replication slot's restart_lsn going backwards. Previously LogicalIncreaseRestartDecodingForSlot() accidentally accepted any LSN as the candidate_lsn and candidate_valid after the restart_lsn of the replication slot was updated, so it potentially caused the restart_lsn to move backwards. A scenario where this could happen in logical replication is: after a logical replication restart, based on previous candidate_lsn and candidate_valid values in memory, the restart_lsn advances upon receiving a subscriber acknowledgment. Then, logical decoding restarts from an older point, setting candidate_lsn and candidate_valid based on an old RUNNING_XACTS record. Subsequent subscriber acknowledgments then update the restart_lsn to an LSN older than the current value. In the reported case, after WAL files were removed by a checkpoint, the retreated restart_lsn prevented logical replication from restarting due to missing WAL segments. This change essentially modifies the 'if' condition to 'else if' condition within the function. The previous code had an asymmetry in this regard compared to LogicalIncreaseXminForSlot(), which does almost the same thing for different fields. The WAL removal issue was reported by Hubert Depesz Lubaczewski. Backpatch to all supported versions, since the bug exists since 9.4 where logical decoding was introduced. Reviewed-by: Tomas Vondra, Ashutosh Bapat, Amit Kapila Discussion: https://postgr.es/m/Yz2hivgyjS1RfMKs%40depesz.com Discussion: https://postgr.es/m/85fff40e-148b-4e86-b921-b4b846289132%40vondra.me Backpatch-through: 13 Branch ------ REL_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/91771b3fbbc33e066e9a28a7d85bde87f5a0c900 Modified Files -------------- src/backend/replication/logical/logical.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix a possibility of logical replication slot's restart_lsn goin @ 2024-11-16 01:07 Masahiko Sawada <msawada@postgresql.org> 0 siblings, 0 replies; 6+ messages in thread From: Masahiko Sawada @ 2024-11-16 01:07 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix a possibility of logical replication slot's restart_lsn going backwards. Previously LogicalIncreaseRestartDecodingForSlot() accidentally accepted any LSN as the candidate_lsn and candidate_valid after the restart_lsn of the replication slot was updated, so it potentially caused the restart_lsn to move backwards. A scenario where this could happen in logical replication is: after a logical replication restart, based on previous candidate_lsn and candidate_valid values in memory, the restart_lsn advances upon receiving a subscriber acknowledgment. Then, logical decoding restarts from an older point, setting candidate_lsn and candidate_valid based on an old RUNNING_XACTS record. Subsequent subscriber acknowledgments then update the restart_lsn to an LSN older than the current value. In the reported case, after WAL files were removed by a checkpoint, the retreated restart_lsn prevented logical replication from restarting due to missing WAL segments. This change essentially modifies the 'if' condition to 'else if' condition within the function. The previous code had an asymmetry in this regard compared to LogicalIncreaseXminForSlot(), which does almost the same thing for different fields. The WAL removal issue was reported by Hubert Depesz Lubaczewski. Backpatch to all supported versions, since the bug exists since 9.4 where logical decoding was introduced. Reviewed-by: Tomas Vondra, Ashutosh Bapat, Amit Kapila Discussion: https://postgr.es/m/Yz2hivgyjS1RfMKs%40depesz.com Discussion: https://postgr.es/m/85fff40e-148b-4e86-b921-b4b846289132%40vondra.me Backpatch-through: 13 Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/f353911337cf0c291527528a9b21941a1a83fead Modified Files -------------- src/backend/replication/logical/logical.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix a possibility of logical replication slot's restart_lsn goin @ 2024-11-16 01:07 Masahiko Sawada <msawada@postgresql.org> 0 siblings, 0 replies; 6+ messages in thread From: Masahiko Sawada @ 2024-11-16 01:07 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix a possibility of logical replication slot's restart_lsn going backwards. Previously LogicalIncreaseRestartDecodingForSlot() accidentally accepted any LSN as the candidate_lsn and candidate_valid after the restart_lsn of the replication slot was updated, so it potentially caused the restart_lsn to move backwards. A scenario where this could happen in logical replication is: after a logical replication restart, based on previous candidate_lsn and candidate_valid values in memory, the restart_lsn advances upon receiving a subscriber acknowledgment. Then, logical decoding restarts from an older point, setting candidate_lsn and candidate_valid based on an old RUNNING_XACTS record. Subsequent subscriber acknowledgments then update the restart_lsn to an LSN older than the current value. In the reported case, after WAL files were removed by a checkpoint, the retreated restart_lsn prevented logical replication from restarting due to missing WAL segments. This change essentially modifies the 'if' condition to 'else if' condition within the function. The previous code had an asymmetry in this regard compared to LogicalIncreaseXminForSlot(), which does almost the same thing for different fields. The WAL removal issue was reported by Hubert Depesz Lubaczewski. Backpatch to all supported versions, since the bug exists since 9.4 where logical decoding was introduced. Reviewed-by: Tomas Vondra, Ashutosh Bapat, Amit Kapila Discussion: https://postgr.es/m/Yz2hivgyjS1RfMKs%40depesz.com Discussion: https://postgr.es/m/85fff40e-148b-4e86-b921-b4b846289132%40vondra.me Backpatch-through: 13 Branch ------ REL_17_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/568e78a653ee9f96796e3bb7e38da7afd6786eb9 Modified Files -------------- src/backend/replication/logical/logical.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix a possibility of logical replication slot's restart_lsn goin @ 2024-11-16 01:07 Masahiko Sawada <msawada@postgresql.org> 0 siblings, 0 replies; 6+ messages in thread From: Masahiko Sawada @ 2024-11-16 01:07 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix a possibility of logical replication slot's restart_lsn going backwards. Previously LogicalIncreaseRestartDecodingForSlot() accidentally accepted any LSN as the candidate_lsn and candidate_valid after the restart_lsn of the replication slot was updated, so it potentially caused the restart_lsn to move backwards. A scenario where this could happen in logical replication is: after a logical replication restart, based on previous candidate_lsn and candidate_valid values in memory, the restart_lsn advances upon receiving a subscriber acknowledgment. Then, logical decoding restarts from an older point, setting candidate_lsn and candidate_valid based on an old RUNNING_XACTS record. Subsequent subscriber acknowledgments then update the restart_lsn to an LSN older than the current value. In the reported case, after WAL files were removed by a checkpoint, the retreated restart_lsn prevented logical replication from restarting due to missing WAL segments. This change essentially modifies the 'if' condition to 'else if' condition within the function. The previous code had an asymmetry in this regard compared to LogicalIncreaseXminForSlot(), which does almost the same thing for different fields. The WAL removal issue was reported by Hubert Depesz Lubaczewski. Backpatch to all supported versions, since the bug exists since 9.4 where logical decoding was introduced. Reviewed-by: Tomas Vondra, Ashutosh Bapat, Amit Kapila Discussion: https://postgr.es/m/Yz2hivgyjS1RfMKs%40depesz.com Discussion: https://postgr.es/m/85fff40e-148b-4e86-b921-b4b846289132%40vondra.me Backpatch-through: 13 Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/e5ed873b1b4a395b06a5599100383a95c9846e5b Modified Files -------------- src/backend/replication/logical/logical.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2024-11-16 01:07 UTC | newest] Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2024-11-16 01:07 pgsql: Fix a possibility of logical replication slot's restart_lsn goin Masahiko Sawada <msawada@postgresql.org> 2024-11-16 01:07 pgsql: Fix a possibility of logical replication slot's restart_lsn goin Masahiko Sawada <msawada@postgresql.org> 2024-11-16 01:07 pgsql: Fix a possibility of logical replication slot's restart_lsn goin Masahiko Sawada <msawada@postgresql.org> 2024-11-16 01:07 pgsql: Fix a possibility of logical replication slot's restart_lsn goin Masahiko Sawada <msawada@postgresql.org> 2024-11-16 01:07 pgsql: Fix a possibility of logical replication slot's restart_lsn goin Masahiko Sawada <msawada@postgresql.org> 2024-11-16 01:07 pgsql: Fix a possibility of logical replication slot's restart_lsn goin Masahiko Sawada <msawada@postgresql.org>
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