On Dec 3, 2015, at 4:18 AM, Craig Ringer wrote:

> Excellent.
> It should be possible to make that a separate extension. You can use C 
> functions from other extensions by exposing a single pg_proc function with 
> 'internal' return type that populates a struct of function pointers for the 
> API. A single DirectFunctionCall lets you get the API struct. That's how 
> pglogical_output handles hooks. The main downside is that you can't do that 
> without a connection to a database with the extension installed so the 
> pg_proc entry is exposed.

Actually, working under cluster and columnar storage extension I got several 
questions about PostgreSQL infrastructure.
I always found some workarounds, but may it is better to ask community about 

1. Why there is no "conditional event" synchronization primitive in PostgreSQL. 
There is latch, but it is implemented using sockets and I afraid that it is not 
very fast.
It will be nice to have some fast primitive like pthread condition variables.

2. PostgreSQL semaphores seems to be not intended for external use outside 
PostgreSQL core  (for example in extensions).
There is no way to request additional amount of semaphores. Right now 
semaphores are allocated based on maximal number of backends and spinlocks.
And a semaphore as well as event is very popular and convenient synchronization 
primitive required in many cases.

3. What is the right way of creation of background worker requiring access to 
shared memory, i.e. having control structure in main memory?
As far as I understand background workers have to be registered either PG_init, 
either outside Postmaster environment.
If extension requires access to shared memory, then it should be registered in 
shared_preload_libraries list and should be initialized using shmem_startup 
Something like this:

void _PG_init(void)
        if (!process_shared_preload_libraries_in_progress)
        prev_shmem_startup_hook = shmem_startup_hook;
        shmem_startup_hook = My_shmem_startup;

My_shmem_startup is needed because in _PG_init it is not possible to allocate 
shared memory.
So if I need to allocate some control structure for background workers  in 
shared memory, then I should do it in My_shmem_startup.
But I can not register background workers in My_shmem_startup! I will get "must 
be registered in shared_preload_libraries" error:

RegisterBackgroundWorker(BackgroundWorker *worker)
        if (!process_shared_preload_libraries_in_progress)
                if (!IsUnderPostmaster)
                                         errmsg("background worker \"%s\": must 
be registered in shared_preload_libraries",

So I have to register background workers in PG_init while control structure for 
them is not yet ready.
When I have implemented pool of background workers, I solved this problem by 
proving function which return address of control structure later - when it will 
be actually allocated.
But it seems to be some design flaw in BGW, isn' it?

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

Reply via email to