From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Andres Freund <andres(at)2ndquadrant(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: parallel mode and parallel contexts |
Date: | 2015-01-21 07:11:21 |
Message-ID: | CAA4eK1Lrbhcq-s-_vjT00U_Gm8JKyna9B+9mCrzhKEuj9=X5UA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jan 20, 2015 at 9:52 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> On Tue, Jan 20, 2015 at 9:41 AM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
wrote:
> > It seems [WaitForBackgroundWorkerShutdown] 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.
>
> I don't think that's right. The status only remains
> BGWH_NOT_YET_STARTED until the postmaster forks the child process.
I think the control flow can reach the above location before
postmaster could fork all the workers. Consider a case that
we have launched all workers during ExecutorStart phase
and then before postmaster could start all workers an error
occurs in master backend and then it try to Abort the transaction
and destroy the parallel context, at that moment it will get the
above status and wait forever in above code.
I am able to reproduce above scenario with debugger by using
parallel_seqscan patch.
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Langote | 2015-01-21 07:17:24 | Re: Parallel Seq Scan |
Previous Message | Abhijit Menon-Sen | 2015-01-21 06:42:56 | Re: pgaudit - an auditing extension for PostgreSQL |