Re: Be strict when request to flush past end of WAL in WaitXLogInsertionsToFinish

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

In response to

Browse pgsql-hackers by date

  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