Re: parallel mode and parallel contexts - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: parallel mode and parallel contexts
Date
Msg-id CAA4eK1K8mZ+B1pSUhaij9G0bSUSKhwuWy6cCvx17ZEYup16MLg@mail.gmail.com
Whole thread Raw
In response to Re: parallel mode and parallel contexts  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: parallel mode and parallel contexts
List pgsql-hackers
On Sat, Jan 17, 2015 at 3:40 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>
> New patch attached.  I'm going to take the risk of calling this v1
> (previous versions have been 0.x), since I've now done something about
> the heavyweight locking issue, as well as fixed the message-looping
> bug Amit pointed out.  It doubtless needs more work, but it's starting
> to smell a bit more like a real patch.
>

I need some clarification regarding below code:

+BgwHandleStatus
+WaitForBackgroundWorkerShutdown(BackgroundWorkerHandle *handle)
+{
+ BgwHandleStatus 
status;
+ int rc;
+ bool save_set_latch_on_sigusr1;
+
+
save_set_latch_on_sigusr1 = set_latch_on_sigusr1;
+ set_latch_on_sigusr1 = true;
+
+ PG_TRY();
+ {
+
for (;;)
+ {
+ pid_t pid;
+
+
CHECK_FOR_INTERRUPTS();
+
+ status = GetBackgroundWorkerPid(handle, &pid);
+
if (status == BGWH_STOPPED)
+ return status;
+
+ rc = 
WaitLatch(&MyProc->procLatch,
+   WL_LATCH_SET | 
WL_POSTMASTER_DEATH, 0);
+
+ if (rc & WL_POSTMASTER_DEATH)
+
return BGWH_POSTMASTER_DIED;

It seems this code has possibility to wait forever.
Assume one of the worker is not able to start (not able to attach
to shared memory or some other reason), then status returned by
GetBackgroundWorkerPid() will be BGWH_NOT_YET_STARTED
and after that it can wait forever in WaitLatch.


With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Dereferenced pointers checked as NULL in btree_utils_var.c
Next
From: Tom Lane
Date:
Subject: Re: New CF app deployment