Re: Proof of concept: standalone backend with full FE/BE protocol
Heikki Linnakangas <hlinnaka@iki.fi>
From: Heikki Linnakangas <hlinnaka@iki.fi>
To: Gurjeet Singh <singh.gurjeet@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgresql.org
Date: 2012-09-10T15:43:12Z
Lists: 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
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Remove now redundant pgpipe code.
- d2c1740dc275 9.2.0 cited