On Mon, Feb 2, 2026 at 11:11 PM Fujii Masao <masao.fujii@gmail.com> wrote:
>
> On Sun, Feb 1, 2026 at 3:00 AM Alexander Lakhin <exclusion@gmail.com> wrote:
> >
> > Hello Fujii-san,
> >
> > 06.01.2026 05:02, Fujii Masao wrote:
> > > On Thu, Dec 25, 2025 at 4:00 PM Fujii Masao <masao.fujii@gmail.com> 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.
I've pushed the patch. Thanks!
Regards,
--
Fujii Masao
