libpq enhancement for multi-process application

Поиск
Список
Период
Сортировка
От Sébastien Bonnet
Тема libpq enhancement for multi-process application
Дата
Msg-id 3A3F6BF9.886CFF70@free.fr
обсуждение исходный текст
Список pgsql-hackers
Hi all, and mainly postresql developpers,

I've been reading old posts about the libpq interface related to multi-process
application. The main problem being that after a fork, each process has a DB
connexion, actually the same. If one closes it, the other one remains in a
unknown or not stable state.

This is a real problem when writing a highly loaded daemon. Let's consider my
example : a main daemon is receiving network requests, and makes heavy use of
the DB. It thus have a permanent connexion to the DB. Sometimes, this main
daemon forks, just to serve a couple of request. This child process doesn't
need a permanent connexion. But closing it would destroy his parent's one.

There is actually one very easy, but awful, solution : closing the database
connexion before forking, and reopening when needed in each process. But
that's really awful, cause the main daemon will always close, fork, and then
just after reopen. What a waste !

A second solution would be a clone of the PQfinish function which does NOT
send the disconnexion sequence to the backend but just does everything else
(release memory, close the socket, and so on).

The big frustration being that this clone actually exists in the library, but
is a private function. It's named freePGconn, and is called from PQfinish
besides closePGconn (which sends the disconnexion sequence to the backend).

So I guess you've understood my request. Great folks from postresql, would it
be possible to kinda export a nice version of freePGconn ? It would really,
really, help people writing multi-process application without having to manage
a single connexion with shared memory and other tricks, as suggested a few
months ago.

In the meantime, I use the ugly solution : freeing the pointer returned by
PQconnectdb in the child process, knowing some memory hasn't been released.
Hopefully, these child processes don't last long, and the garbage collector is
working fine !


Comments / other solutions are welcome !

Regards,

-- 
Sébastien Bonnet bonseb@free.fr                                 http://bonseb.free.fr/


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Alex Pilosov
Дата:
Сообщение: Re: performance modality in 7.1 for large text attributes?
Следующее
От: "Hiroshi Inoue"
Дата:
Сообщение: Isn't init_irels() dangerous ?