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 по дате отправления: