On Sun, Feb 1, 2026 at 3:00 AM Alexander Lakhin <[email protected]> wrote: > > Hello Fujii-san, > > 06.01.2026 05:02, Fujii Masao wrote: > > On Thu, Dec 25, 2025 at 4:00 PM Fujii Masao <[email protected]> wrote: > >> OK, I've updated the 0002 patch accordingly. > > I've pushed the patches. Thanks all! > > Buildfarm animal sungazer has revealed a test defect coined with 5f13999aa
Thanks for the report! > [1]: > # Failed test 'log_statement_stats in CONNECTION string had effect on > publisher's walsender' > # at t/001_rep_changes.pl line 460. > # '' > # doesn't match '(?^:QUERY STATISTICS)' > # Looks like you failed 1 test of 37. > [11:37:37] t/001_rep_changes.pl ............... > Dubious, test returned 1 (wstat 256, 0x100) > Failed 1/37 subtests > > That is, it managed to read empty log contents here: > # Check that the expected QUERY STATISTICS message appears, > # which shows that log_statement_stats=on from the CONNECTION string > # was correctly passed through to and honored by the walsender. > $logfile = slurp_file($node_publisher->logfile, $log_location); > > I believe that's because $log_location is set above for the other log file: > my $log_location = -s $node_subscriber->logfile; You're right! I've attached a patch that fixes the test to use the correct log position (i.e.,, the publisher's own log position) when reading the publisher's log file. Currently, a single $log_location variable is used for both the publisher's and subscriber's log positions, which is confusing and can easily lead to bugs like this. To avoid similar issues in the future, the patch also splits this variable into $log_location_pub and $log_location_sub, clearly distinguishing the two. Regards, -- Fujii Masao
From 926832519ed9058241662b4b21afa7c9eacf7b67 Mon Sep 17 00:00:00 2001 From: Fujii Masao <[email protected]> Date: Mon, 2 Feb 2026 22:58:46 +0900 Subject: [PATCH v1] Fix logical replication TAP test to read publisher log correctly. Commit 5f13999aa11 added a TAP test for GUC settings passed via the CONNECTION string in logical replication, but the buildfarm member sungazer reported test failures. The test incorrectly used the subscriber's log file position as the starting offset when reading the publisher's log. As a result, the test failed to find the expected log message in the publisher's log and erroneously reported a failure. This commit fixes the test to use the publisher's own log file position when reading the publisher's log. Also, to avoid similar confusion in the future, this commit splits the single $log_location variable into $log_location_pub and $log_location_sub, clearly distinguishing publisher and subscriber log positions. Backpatched to v15, where commit 5f13999aa11 introduced the test. Per buildfarm member sungazer. This issue was reported and diagnosed by Alexander Lakhin. Reported-by: Alexander Lakhin <[email protected]> Discussion: https://postgr.es/m/[email protected] Backpatch-through: 15 --- src/test/subscription/t/001_rep_changes.pl | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/src/test/subscription/t/001_rep_changes.pl b/src/test/subscription/t/001_rep_changes.pl index fb9ec6f79ab..4fdee085227 100644 --- a/src/test/subscription/t/001_rep_changes.pl +++ b/src/test/subscription/t/001_rep_changes.pl @@ -353,7 +353,8 @@ $node_subscriber->safe_psql('postgres', "DELETE FROM tab_full WHERE a = 25"); # Note that the current location of the log file is not grabbed immediately # after reloading the configuration, but after sending one SQL command to # the node so as we are sure that the reloading has taken effect. -my $log_location = -s $node_subscriber->logfile; +my $log_location_pub = -s $node_publisher->logfile; +my $log_location_sub = -s $node_subscriber->logfile; $node_publisher->safe_psql('postgres', "UPDATE tab_full_pk SET b = 'quux' WHERE a = 1"); @@ -363,7 +364,7 @@ $node_publisher->safe_psql('postgres', "DELETE FROM tab_full_pk WHERE a = 2"); $node_publisher->wait_for_catchup('tap_sub'); -my $logfile = slurp_file($node_subscriber->logfile, $log_location); +my $logfile = slurp_file($node_subscriber->logfile, $log_location_sub); ok( $logfile =~ qr/conflict detected on relation "public.tab_full_pk": conflict=update_missing.*\n.*DETAIL:.* Could not find the row to be updated.*\n.*Remote row \(1, quux\); replica identity \(a\)=\(1\)/m, 'update target row is missing'); @@ -442,11 +443,12 @@ is( $result, qq(11.11|baz|1 # # First, confirm that no such QUERY STATISTICS message appears before enabling # log_statement_stats. -$logfile = slurp_file($node_publisher->logfile, $log_location); +$logfile = slurp_file($node_publisher->logfile, $log_location_pub); unlike( $logfile, qr/QUERY STATISTICS/, 'log_statement_stats has not been enabled yet'); +$log_location_pub = -s $node_publisher->logfile; # check that change of connection string and/or publication list causes # restart of subscription workers. We check the state along with @@ -473,7 +475,7 @@ $node_publisher->poll_query_until('postgres', # Check that the expected QUERY STATISTICS message appears, # which shows that log_statement_stats=on from the CONNECTION string # was correctly passed through to and honored by the walsender. -$logfile = slurp_file($node_publisher->logfile, $log_location); +$logfile = slurp_file($node_publisher->logfile, $log_location_pub); like( $logfile, qr/QUERY STATISTICS/, @@ -535,13 +537,13 @@ $node_publisher->reload; # Note that the current location of the log file is not grabbed immediately # after reloading the configuration, but after sending one SQL command to # the node so that we are sure that the reloading has taken effect. -$log_location = -s $node_publisher->logfile; +$log_location_pub = -s $node_publisher->logfile; $node_publisher->safe_psql('postgres', "INSERT INTO tab_notrep VALUES (11)"); $node_publisher->wait_for_catchup('tap_sub'); -$logfile = slurp_file($node_publisher->logfile, $log_location); +$logfile = slurp_file($node_publisher->logfile, $log_location_pub); ok($logfile =~ qr/skipped replication of an empty transaction with XID/, 'empty transaction is skipped'); -- 2.51.2
v1-0001-master-Fix-logical-replication-TAP-test-to-read-publishe.patch
Description: Binary data
