From: | Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> |
---|---|
To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Markus Wanner <markus(at)bluegap(dot)ch>, kaigai(at)kaigai(dot)gr(dot)jp, PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Review: Extra Daemons / bgworker |
Date: | 2012-11-30 13:03:57 |
Message-ID: | m2d2yvb5tu.fsf@2ndQuadrant.fr |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andres Freund <andres(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Pavan Deolasee | 2012-11-30 13:05:05 | Re: missing LockBuffer(buffer, BUFFER_LOCK_SHARE) in trigger.c GetTupleForTrigger? |
Previous Message | Andres Freund | 2012-11-30 12:59:15 | Re: Review: Extra Daemons / bgworker |