Re: BUG #17055: Logical replication worker crashes when applying update of row that dose not exist in target partiti

Michael Paquier <michael(at)paquier(dot)xyz> writes:
> +$node_subscriber->append_conf('postgresql.conf', "log_min_messages = debug1");
> +$node_subscriber->reload;
> Wouldn't it be better to make sure that the change is effective before
> moving on to the end of the test?

AFAICS, none of the other callers of sub reload are doing anything
special to wait for it to take effect. Not sure why this one
would need more protection. If we do need a fix for that, likely
sub reload itself had better do it.

> +my $logfile = slurp_file($node_subscriber->logfile());
> +ok( $logfile =~
> + qr/logical replication did not find row to be updated in replication target relation "tab_full_pk"/,
> + 'update target row is missing');
> I think that it would be better here to grab the log location before
> running the queries that will be matched with the logs, then pass down
> the location to slurp_file().

This coding is also stolen verbatim from other test scripts.
What is your concern about it exactly? It's not like the
tests have such varying amounts of log output that an unexpected
log rotation would be likely. (Does the default TAP setup even
allow log rotation at all? I doubt it.)

regards, tom lane