Re: Wait event that should be reported while waiting for WAL archiving to finish

From: Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Wait event that should be reported while waiting for WAL archiving to finish
Date: 2020-02-17 13:21:23
Message-ID: d9d85efa-f62e-400e-2edf-9e1b8c0df651@oss.nttdata.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2020/02/17 18:48, Michael Paquier wrote:
> On Mon, Feb 17, 2020 at 04:30:00PM +0900, Fujii Masao wrote:
>> On 2020/02/14 23:43, Robert Haas wrote:
>>> On Thu, Feb 13, 2020 at 10:47 PM Fujii Masao
>>> <masao(dot)fujii(at)oss(dot)nttdata(dot)com> wrote:
>>>> Fixed. Thanks for the review!
>>>
>>> I think it would be safer to just report the wait event during
>>> pg_usleep(1000000L) rather than putting those calls around the whole
>>> loop. It does not seem impossible that ereport() or
>>> CHECK_FOR_INTERRUPTS() could do something that reports a wait event
>>> internally.
>
> CHECK_FOR_INTERRUPTS() would reset the event wait state. Hm.. You
> may be right about the WARNING and it would be better to not rely on
> that. Do you remember the states which may be triggered?
>
>> OK, so I attached the updated version of the patch.
>> Thanks for the review!
>
> Actually, I have some questions:
> 1) Should a new wait event be added in recoveryPausesHere()? That
> would be IMO useful.

Yes, it's useful, I think. But it's better to implement that
as a separate patch.

> 2) Perhaps those two points should be replaced with WaitLatch(), where
> we would use the new wait events introduced?

For what? Maybe it should, but I'm not sure it's worth the trouble.

Regards,

--
Fujii Masao
NTT DATA CORPORATION
Advanced Platform Technology Group
Research and Development Headquarters

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Sergei Kornilov 2020-02-17 13:57:04 Re: pgsql: walreceiver uses a temporary replication slot by default
Previous Message Fujii Masao 2020-02-17 13:01:30 Re: pg_stat_progress_basebackup - progress reporting for pg_basebackup, in the server side