Обсуждение: [HACKERS] Latches API on windows

On 9 October 2017 at 21:26, Abbas Butt <abbas.butt@enterprisedb.com> wrote:
> Hi,
> I am working on a contrib module that uses RegisterDynamicBackgroundWorker
> API
> to create a couple of worker processes. For synchronization between the
> background worker processes I am using InitSharedLatch, SetLatch, WaitLatch
> APIs.
> One of the processes is supposed to wait for the latch, the other is
> supposed to set it.
> The system works perfectly fine as long as its run on Linux, however when
> tried
> on Windows, it fails giving the error:
> ResetEvent failed: error code 6
> Error code 6 means invalid handle. Debugging reveals that the handle
> contains
> a valid value, however it seems that the handle is not accessible (was not
> created)
> in the process that is calling ResetEvent.
>
> Debugging the issue lead me to the following comment on top of
> InitSharedLatch:
>
>  * InitSharedLatch needs to be called in postmaster before forking child
>  * processes, usually right after allocating the shared memory block
>  * containing the latch with ShmemInitStruct. (The Unix implementation
>  * doesn't actually require that, but the Windows one does.)
>
> In my case this is not true, I am calling InitSharedLatch in _PG_init
> which gets called at CREATE EXTENSION time.
> My question : Is there a way to get the latches API work on windows
> the way it is working on Linux?

I suspect you'd need to do it by having your extension load via
shared_preload_libraries, registering its latch in shmem_startup_hook
.

But ... that's an off-the-cuff guess.

-- Craig Ringer                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Craig Ringer <craig@2ndquadrant.com> writes:
> On 9 October 2017 at 21:26, Abbas Butt <abbas.butt@enterprisedb.com> wrote:
>> In my case this is not true, I am calling InitSharedLatch in _PG_init
>> which gets called at CREATE EXTENSION time.
>> My question : Is there a way to get the latches API work on windows
>> the way it is working on Linux?

> I suspect you'd need to do it by having your extension load via
> shared_preload_libraries, registering its latch in shmem_startup_hook

Yeah.  That would also let you request your shared memory area honestly,
instead of relying on there being some slop in the initial allocation.
        regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On October 9, 2017 6:56:10 AM PDT, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>Craig Ringer <craig@2ndquadrant.com> writes:
>> On 9 October 2017 at 21:26, Abbas Butt <abbas.butt@enterprisedb.com>
>wrote:
>>> In my case this is not true, I am calling InitSharedLatch in
>_PG_init
>>> which gets called at CREATE EXTENSION time.
>>> My question : Is there a way to get the latches API work on windows
>>> the way it is working on Linux?
>
>> I suspect you'd need to do it by having your extension load via
>> shared_preload_libraries, registering its latch in shmem_startup_hook
>
>Yeah.  That would also let you request your shared memory area
>honestly,
>instead of relying on there being some slop in the initial allocation.

Might be dsm  style memory.


I think the right approach here, regardless of the source of the memory, is to actually bit create a new latch, but
insteadto store a pointer the the owning processes preexisting latch. Besides solving this issue, it also avoids
problemswith various routines already waiting on the proclatch. 

Andres

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers