Re: Review: Extra Daemons / bgworker - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Review: Extra Daemons / bgworker
Date
Msg-id 20121130125720.GB4542@alvh.no-ip.org
Whole thread Raw
In response to Re: Review: Extra Daemons / bgworker  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
Responses Re: Review: Extra Daemons / bgworker
List pgsql-hackers
Dimitri Fontaine wrote:
> Markus Wanner <markus@bluegap.ch> writes:
> > AFAICS pgqd currently uses libpq, so I think it would rather turn into
> > what I call a background worker, with a connection to Postgres shared
> > memory. I perfectly well see use cases (plural!) for those.
> >
> > What I'm questioning is the use for what I rather call "extra daemons",
> > that is, additional processes started by the postmaster without a
> > connection to Postgres shared memory (and thus without a database
> > connection).
>
> I totally missed the need to connect to shared memory to be able to
> connect to a database and query it. Can't we just link the bgworkder
> code to the client libpq library, just as plproxy is doing I believe?

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.

--
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: missing LockBuffer(buffer, BUFFER_LOCK_SHARE) in trigger.c GetTupleForTrigger?
Next
From: Andres Freund
Date:
Subject: Re: Re: missing LockBuffer(buffer, BUFFER_LOCK_SHARE) in trigger.c GetTupleForTrigger?