Request a Demo
Home   >   mailing lists

Re: Propagate XLogFindNextRecord error to callers - Mailing list pgsql-hackers

From Anthonin Bonnefoy
Subject Re: Propagate XLogFindNextRecord error to callers
Date
Msg-id CAO6_XqrUzBT70kE20uHH=FWyfGJaTDMwqv++yNppdusywsG8-w@mail.gmail.com
Whole thread
In response to Re: Propagate XLogFindNextRecord error to callers  (Mircea Cadariu <cadariu.mircea@gmail.com>)
Responses Re: Propagate XLogFindNextRecord error to callers
List pgsql-hackers
Tree view 
On Mon, Feb 9, 2026 at 1:15 PM Mircea Cadariu <cadariu.mircea@gmail.com> wrote:
> In XLogNextRecord, right before the above code, we do *errormsg = NULL. Should this be done also in
XLogFindNextRecordin the patch? 
>
> If so, what about even extracting a helper method which will be called from both places?

XLogReadRecord may already have consumed errormsg_deferred and set
errormsg. We can't set it to NULL, or that would erase a valid error
message.

A simplification would have been to remove processing the deferred
error processing from XLogNextRecord and leave it to
XLogFindNextRecord, but there are some calls to XLogNextRecord (like
in xlogprefetcher.c), so being able to get the error message when
calling XLogNextRecord is necessary.

> A nit for the commit message: Propage -> Propagate

Fixed
Attachment

pgsql-hackers by date:

Previous
From: Etsuro Fujita
Date:
Subject: Re: Instability in postgres_fdw regression tests
Next
From: "Zhijie Hou (Fujitsu)"
Date:
Subject: RE: Improve pg_sync_replication_slots() to wait for primary to advance