Re: Review: Extra Daemons / bgworker

Поиск
Список
Период
Сортировка
От Dimitri Fontaine
Тема Re: Review: Extra Daemons / bgworker
Дата
Msg-id m2d2yvb5tu.fsf@2ndQuadrant.fr
обсуждение исходный текст
Ответ на Re: Review: Extra Daemons / bgworker  (Andres Freund <andres@2ndquadrant.com>)
Ответы Re: Review: Extra Daemons / bgworker  (Kohei KaiGai <kaigai@kaigai.gr.jp>)
Список pgsql-hackers
Andres Freund <andres@2ndquadrant.com> writes:
>> One of the uses for bgworkers that don't have shmem connection is to
>> have them use libpq connections instead.  I don't really see the point
>> of forcing everyone to use backend connections when libpq connections
>> are enough.  In particular, they are easier to port from existing code;
>> and they make it easier to share code with systems that still have to
>> support older PG versions.

Exactly, I think most bgworker would just use libpq if that's available,
using a backend's infrastructure is not that good a fit here. I mean,
connect from your worker to a database using libpq and call a backend's
function (provided by the same extension I guess) in there.

That's how I think pgqd would get integrated into the worker
infrastructure, right?

> They also can get away with a lot more crazy stuff without corrupting
> the database. You better know something about what youre doing before
> doing something with direct shared memory access.

And there's a whole lot you can already do just with a C coded stored
procedure already.

Regards,
-- 
Dimitri Fontaine
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Review: Extra Daemons / bgworker
Следующее
От: Pavan Deolasee
Дата:
Сообщение: Re: missing LockBuffer(buffer, BUFFER_LOCK_SHARE) in trigger.c GetTupleForTrigger?