Re: 001_rep_changes.pl fails due to publisher stuck on shutdown

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: 001_rep_changes.pl fails due to publisher stuck on shutdown
Дата
Msg-id CAA4eK1+fb43k-jaDQRucNN--uBM+Zh0Xu21rDfcy-65EVrtm8Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: 001_rep_changes.pl fails due to publisher stuck on shutdown  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Ответы Re: 001_rep_changes.pl fails due to publisher stuck on shutdown
Список pgsql-hackers
On Thu, Jun 6, 2024 at 11:49 AM Kyotaro Horiguchi
<horikyota.ntt@gmail.com> wrote:
>
> At Thu, 6 Jun 2024 12:49:45 +1000, Peter Smith <smithpb2250@gmail.com> wrote in
> > Hi, I have reproduced this multiple times now.
> >
> > I confirmed the initial post/steps from Alexander. i.e. The test
> > script provided [1] gets itself into a state where function
> > ReadPageInternal (called by XLogDecodeNextRecord and commented "Wait
> > for the next page to become available") constantly returns
> > XLREAD_FAIL. Ultimately the test times out because WalSndLoop() loops
> > forever, since it never calls WalSndDone() to exit the walsender
> > process.
>
> Thanks for the repro; I believe I understand what's happening here.
>
> During server shutdown, the latter half of the last continuation
> record may fail to be flushed. This is similar to what is described in
> the commit message of commit ff9f111bce. While shutting down,
> WalSndLoop() waits for XLogSendLogical() to consume WAL up to
> flushPtr, but in this case, the last record cannot complete without
> the continuation part starting from flushPtr, which is
> missing.

Sorry, it is not clear to me why we failed to flush the last
continuation record in logical walsender? I see that we try to flush
the WAL after receiving got_STOPPING in WalSndWaitForWal(), why is
that not sufficient?

--
With Regards,
Amit Kapila.



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

Предыдущее
От: vignesh C
Дата:
Сообщение: Re: Logical Replication of sequences
Следующее
От: Bertrand Drouvot
Дата:
Сообщение: Re: Track the amount of time waiting due to cost_delay