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

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>
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-18 03:39:49
Message-ID: 20200218033949.GD4176@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Feb 17, 2020 at 10:21:23PM +0900, Fujii Masao wrote:
> On 2020/02/17 18:48, Michael Paquier wrote:
>> 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.

No problem for me.

>> 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.

I don't have more to offer than signal handling consistency for both
without relying on pg_usleep()'s behavior depending on the platform,
and power consumption. For the recovery pause, the second argument
may not be worth carrying, but we never had this argument for the
archiving wait, did we? For both, on top of it you don't need to
worry about concurrent issues with the wait events attached around.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Langote 2020-02-18 04:11:06 Re: pg_trigger.tgparentid
Previous Message Thomas Munro 2020-02-18 03:30:32 Re: ssl passphrase callback