Re: A new function to wait for the backend exit after termination

From: Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>
To: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>
Cc: "Hou, Zhijie" <houzj(dot)fnst(at)cn(dot)fujitsu(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Muhammad Usama <m(dot)usama(at)gmail(dot)com>
Subject: Re: A new function to wait for the backend exit after termination
Date: 2021-03-15 05:08:15
Message-ID: 2e108baf-7c23-5de0-b123-fa35e3f843a8@oss.nttdata.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2021/03/15 12:27, Bharath Rupireddy wrote:
> On Sun, Mar 7, 2021 at 2:39 PM Bharath Rupireddy
> <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> wrote:
>> Attaching v7 patch for further review.
>
> Attaching v8 patch after rebasing on to the latest master.

Thanks for rebasing the patch!

- WAIT_EVENT_XACT_GROUP_UPDATE
+ WAIT_EVENT_XACT_GROUP_UPDATE,
+ WAIT_EVENT_BACKEND_TERMINATION

These should be listed in alphabetical order.

In pg_wait_until_termination's do-while loop, ResetLatch() should be called. Otherwise, it would enter busy-loop after any signal arrives. Because the latch is kept set and WaitLatch() always exits immediately in that case.

+ /*
+ * Wait in steps of waittime milliseconds until this function exits or
+ * timeout.
+ */
+ int64 waittime = 10;

10 ms per cycle seems too frequent?

+ ereport(WARNING,
+ (errmsg("timeout cannot be negative or zero: %lld",
+ (long long int) timeout)));
+
+ result = false;

IMO the parameter should be verified before doing the actual thing.

Why is WARNING thrown in this case? Isn't it better to throw ERROR like pg_promote() does?

Regards,

--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2021-03-15 05:08:22 Re: Consider Parallelism While Planning For REFRESH MATERIALIZED VIEW
Previous Message Michael Paquier 2021-03-15 05:07:46 Re: Procedures versus the "fastpath" API