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.
