Re: Proof of concept: standalone backend with full FE/BE protocol
От | Heikki Linnakangas |
---|---|
Тема | Re: Proof of concept: standalone backend with full FE/BE protocol |
Дата | |
Msg-id | 504E0A90.7080400@iki.fi обсуждение исходный текст |
Ответ на | Re: Proof of concept: standalone backend with full FE/BE protocol (Gurjeet Singh <singh.gurjeet@gmail.com>) |
Ответы |
Re: Proof of concept: standalone backend with full FE/BE protocol
|
Список | pgsql-hackers |
On 10.09.2012 18:12, Gurjeet Singh wrote: > On Sun, Sep 2, 2012 at 8:23 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote: > >> Notably, while the lack of any background processes is just what you want >> for pg_upgrade and disaster recovery, an ordinary application is probably >> going to want to rely on autovacuum; and we need bgwriter and other >> background processes for best performance. So I'm speculating about >> having a postmaster process that isn't listening on any ports, but is >> managing background processes in addition to a single child backend. >> That's for another day though. > > Since we are forking a child process anyway, and potentially other > auxiliary processes too, would it make sense to allow multiple backends too > (allow multiple local applications connect to this instance)? I believe (I > may be wrong) that embedded databases (SQLLite et. al.) use a library > interface, in that the application makes a library call and waits for that > API call to finish (unless, of course, the library supports async > operations or the application uses threads). The implementation you are > proposing uses socket communication, which lends itself very easily to > client-server model, and if possible, it should be leveraged to provide for > multiple applications talking to one local DB. [scratches head] How's that different from the normal postmaster mode? - Heikki
В списке pgsql-hackers по дате отправления: