Re: BackendPidGetProc doesn't return PGPROC for background worker?

From: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: BackendPidGetProc doesn't return PGPROC for background worker?
Date: 2015-05-15 02:11:47
Message-ID: 555555E3.6000503@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2015-05-15 AM 10:59, Amit Langote wrote:
> On 2015-05-15 AM 10:39, Amit Langote wrote:
>> On 2015-05-15 AM 05:01, Pavel Stehule wrote:
>>>
>>> I am trying to start bgworker from bgworker and create communication
>>> between these process. I have a code based on test_shm_mq. This code fails
>>> because BackendPidGetProc doesn't find related bgworker process, although
>>> the registrant process is living
>>>
>>
>> One reason for this may be that the worker was not started with the flag
>> BGWORKER_SHMEM_ACCESS which is necessary to perform InitProcess() that would
>> initialize a PGPROC entry for it. But if you'd used the same method for
>> initializing workers as test_shm_mq_setup(), then it should have.
>>
>
> It seems in addition, a BackgroundWorkerInitializeConnection() is also
> necessary for the PGPROC entry of the worker to be visible to others. I do not
> see that done anywhere in test_shm_mq(); so perhaps that's missing?
>

And these conditions apply to the bgworker that started another bgworker, that
is the registrant bgworker. I think such a pattern does not exist in existing
code. That is, normally all workers are started by a user backend that has a
valid shared PGPROC entry.

Thanks,
Amit

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2015-05-15 02:35:49 Re: Fix token exceeding NAMELEN
Previous Message Bruce Momjian 2015-05-15 02:06:11 Re: pg_upgrade cleanup