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
