From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Be strict when request to flush past end of WAL in WaitXLogInsertionsToFinish |
Date: | 2024-03-19 04:58:57 |
Message-ID: | d8558c1da22404e16f320c8fc634392a24c0bb25.camel@j-davis.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, 2024-03-15 at 13:12 +0530, Bharath Rupireddy wrote:
> Hi,
>
> While working on [1], it was identified that
> WaitXLogInsertionsToFinish emits a LOG message, and adjusts the upto
> ptr to proceed further when caller requests to flush past the end of
> generated WAL. There's a comment explaining no caller should ever do
> that intentionally except in cases with bogus LSNs. For a similar
> situation, XLogWrite emits a PANIC "xlog write request %X/%X is past
> end of log %X/%X". Although there's no problem if
> WaitXLogInsertionsToFinish emits LOG, but why can't it be a bit more
> harsh and emit PANIC something like the attached to detect the corner
> case?
>
> Thoughts?
I'm not clear on why the callers of WaitXLogInsertionsToFinish() are
handling errors the way they are. XLogWrite PANICs, XLogFlush ERRORs
(which is likely to be escalated to a PANIC anyway), and the other
callers ignore the return value and leave it up to XLogWrite() to
PANIC.
As far as I can tell, once WaitXLogInsertionsToFinish() detects this
bogus LSN, a PANIC is a likely outcome, so your proposed change makes
sense. But then why are the callers also checking?
I haven't looked in a lot of detail.
Regards,
Jeff Davis
From | Date | Subject | |
---|---|---|---|
Next Message | Masahiko Sawada | 2024-03-19 05:09:36 | Re: New Table Access Methods for Multi and Single Inserts |
Previous Message | Hayato Kuroda (Fujitsu) | 2024-03-19 04:54:23 | RE: speed up a logical replica setup |