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

Поиск
Список
Период
Сортировка
От Jeff Davis
Тема Re: Be strict when request to flush past end of WAL in WaitXLogInsertionsToFinish
Дата
Msg-id d8558c1da22404e16f320c8fc634392a24c0bb25.camel@j-davis.com
обсуждение исходный текст
Ответ на Be strict when request to flush past end of WAL in WaitXLogInsertionsToFinish  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
Список 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




В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Hayato Kuroda (Fujitsu)"
Дата:
Сообщение: RE: speed up a logical replica setup
Следующее
От: Masahiko Sawada
Дата:
Сообщение: Re: New Table Access Methods for Multi and Single Inserts