On 2012-11-30 09:57:20 -0300, Alvaro Herrera wrote: > 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.
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
