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
it:)
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
hook.
Something like this:
void _PG_init(void)
{
if (!process_shared_preload_libraries_in_progress)
return;
...
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:
void
RegisterBackgroundWorker(BackgroundWorker *worker)
{
if (!process_shared_preload_libraries_in_progress)
{
if (!IsUnderPostmaster)
ereport(LOG,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("background worker \"%s\": must
be registered in shared_preload_libraries",
worker->bgw_name)));
return;
}
}
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:
http://www.postgresql.org/mailpref/pgsql-hackers
