Re: Fix src/test/subscription/t/029_on_error.pl test when wal_debug is enabled
Amit Kapila <amit.kapila16@gmail.com>
From: Amit Kapila <amit.kapila16@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Ilyasov Ian <ianilyasov@outlook.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2024-05-20T11:09:13Z
Lists: pgsql-hackers
On Fri, May 17, 2024 at 5:25 AM Michael Paquier <michael@paquier.xyz> wrote: > > On Thu, May 16, 2024 at 09:00:47AM +0530, Amit Kapila wrote: > > This can only be a problem if the apply worker generates more LOG > > entries with the required context but it won't do that unless there is > > an operation on the publisher to replicate. If we see any such danger > > then I agree this can break on some slow machines but as of now, I > > don't see any such race condition. > > Perhaps, still I'm not completely sure if this assumption is going to > always stand for all the possible configurations we support. > As per my understanding, this will primarily rely on the apply worker design, not the other configurations, whether we see additional LOG. > So, > rather than coming back to this test again, I would choose to make the > test as stable as possible from the start. That's what mapping with > the error message would offer when grabbing the LSN from the CONTEXT > part of it, because there's a one-one mapping between the expected > ERROR and its CONTEXT from which the information used by the test is > retrieved. > I was slightly hesitant to do an ERROR string-based check because the error string can change and it doesn't seem to bring additional stability for this particular test. But if you and others are still not convinced with the simple fix suggested by me then feel free to proceed with an error-string based check. -- With Regards, Amit Kapila.
Commits
-
Improve stability of subscription/029_on_error.pl
- 8e16f81f3db4 15.8 landed
- 338fb8714c6c 16.4 landed
- ac8c85d04b13 17.0 landed