Dimitri Fontaine wrote: > Markus Wanner <mar...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
