Re: Fix src/test/subscription/t/029_on_error.pl test when wal_debug is enabled - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Fix src/test/subscription/t/029_on_error.pl test when wal_debug is enabled
Date
Msg-id ZkUzgHfiWx9Eh3YA@paquier.xyz
Whole thread Raw
In response to Re: Fix src/test/subscription/t/029_on_error.pl test when wal_debug is enabled  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: Fix src/test/subscription/t/029_on_error.pl test when wal_debug is enabled
List pgsql-hackers
On Wed, May 15, 2024 at 05:58:18PM +0530, Amit Kapila wrote:
> I guess it could be more work if we want to enhance the test for
> ERRORs other than the primary key violation.

And?  You could pass the ERROR string expected as argument of the
function if more flexibility is wanted at some point, no?  It happens
that you don't require that now, which is fine for the three scenarios
calling test_skip_lsn.

> One simple fix is to
> update the log_offset to the location of the LOG after successful
> replication of un-conflicted data. For example, the Log location after
> we execute the below line in the test:
>
> # Check replicated data
>                my $res =
>                  $node_subscriber->safe_psql('postgres', "SELECT
> count(*) FROM tbl");
>                is($res, $expected, $msg);

That still looks like a shortcut to me, weak to race conditions on
slow machines where more log entries could be generated in-between.
So it seems to me that you'd still want to make sure that the CONTEXT
from which the LSN is retrieved maps to the sole expected error.  This
is not going to be stable unless there are stronger checks to avoid
log entries that can parasite the output, and a stronger matching
ensures that.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Introduce new multi insert Table AM and improve performance of various SQL commands with it for Heap AM
Next
From: Thomas Munro
Date:
Subject: Re: Why is citext/regress failing on hamerkop?