Re: Dependency between bgw_notify_pid and bgw_flags - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Dependency between bgw_notify_pid and bgw_flags
Date
Msg-id CA+TgmoZ8Eu=r9=YaAtA8-W-R0DCf-_gpNk1gaJkNJgEroOnJXA@mail.gmail.com
Whole thread Raw
In response to Re: Dependency between bgw_notify_pid and bgw_flags  (Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>)
Responses Re: Dependency between bgw_notify_pid and bgw_flags  (Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>)
List pgsql-hackers
On Tue, Jul 7, 2015 at 4:34 AM, Ashutosh Bapat
<ashutosh.bapat@enterprisedb.com> wrote:
> With that notion of backend, to fix the original problem I reported,
> PostmasterMarkPIDForWorkerNotify() should also look at the
> BackgroundWorkerList. As per the comments in the prologue of this function,
> it assumes that only backends need to be notified about worker state change,
> which looks too restrictive. Any backend or background worker, which wants
> to be notified about a background worker it requested to be spawned, should
> be allowed to do so.

Yeah.  I'm wondering if we should fix this problem by just insisting
that all workers have an entry in BackendList.  At first look, this
seems like it would make the code a lot simpler and have virtually no
downside.  As it is, we're repeatedly reinventing new and different
ways for unconnected background workers to do things that work fine in
all other cases, and I don't see the point of that.

I haven't really tested the attached patch - sadly, we have no testing
of background workers without shared memory access in the tree - but
it shows what I have in mind.

Thoughts?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Attachment

pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: More work on SortSupport for text - strcoll() and strxfrm() caching
Next
From: Ildus Kurbangaliev
Date:
Subject: Re: RFC: replace pg_stat_activity.waiting with something more descriptive