Re: Allow GUC settings in CREATE SUBSCRIPTION CONNECTION to take effect

On Sun, Feb 1, 2026 at 3:00 AM Alexander Lakhin <exclusion(at)gmail(dot)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(dot)fujii(at)gmail(dot)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.

Regards,

--
Fujii Masao