Re: shm_mq_set_sender() crash - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: shm_mq_set_sender() crash
Date
Msg-id CAA4eK1L6ZEd+R9Wo5jLtX12ohy+FjHMMe7Y_Rr27E9mEgOht+Q@mail.gmail.com
Whole thread Raw
In response to shm_mq_set_sender() crash  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: shm_mq_set_sender() crash  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Fri, Aug 26, 2016 at 6:20 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Latest from lorikeet:
> http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=lorikeet&dt=2016-08-26%2008%3A37%3A27
>
> TRAP: FailedAssertion("!(vmq->mq_sender == ((void *)0))", File:
"/home/andrew/bf64/root/REL9_6_STABLE/pgsql.build/../pgsql/src/backend/storage/ipc/shm_mq.c",Line: 220)
 
>

Do you think, it is due to some recent change or we are just seeing
now as it could be timing specific issue?

So here what seems to be happening is that during worker startup, we
are trying to set the sender for a shared memory queue and the same is
already set.  Now, one theoretical possibility of the same could be
that the two workers get the same ParallelWorkerNumber which is then
used to access the shm queue (refer
ParallelWorkerMain/ExecParallelGetReceiver).  We are setting the
ParallelWorkerNumber in below code which seems to be doing what it is
suppose to do:

LaunchParallelWorkers()
{
..
for (i = 0; i < pcxt->nworkers; ++i)
{
memcpy(worker.bgw_extra, &i, sizeof(int));
if (!any_registrations_failed &&
RegisterDynamicBackgroundWorker(&worker,
&pcxt->worker[i].bgwhandle))
..
}

Can some reordering impact the above code?


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



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: WAL consistency check facility
Next
From: Michael Paquier
Date:
Subject: Re: Renaming of pg_xlog and pg_clog