On 2012-11-30 09:57:20 -0300, Alvaro Herrera wrote:
> 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.
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.
Greetings,
Andres Freund
--Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services
