Re: Proof of concept: standalone backend with full FE/BE protocol

From: Gurjeet Singh <singh(dot)gurjeet(at)gmail(dot)com>
To: hlinnaka(at)iki(dot)fi
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Proof of concept: standalone backend with full FE/BE protocol
Date: 2012-09-10 16:25:00
Message-ID: CABwTF4VX-bS=mdTuXXyDfzuw6UPmZbG0NWgyv+FSu3Va=w3=-g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Sep 10, 2012 at 11:43 AM, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>wrote:

> On 10.09.2012 18:12, Gurjeet Singh wrote:
>
>> On Sun, Sep 2, 2012 at 8:23 PM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)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?

As I described in later paragraphs, it'd behave like an embedded database,
like SQLite etc., so the database will startup and shutdown with the
application, and provide other advantages we're currently trying to
provide, like zero-maintenance. But it will not mandate that only one
application talk to it at a time, and allow as many applications as it
would in postmaster mode. So the database would be online as long as any
application is connected to it, and it will shutdown when the last
application disconnects.

As being implemented right now, there's very little difference between
--single and --child modes. I guess I am asking for a --child mode
implementation that is closer to a postmaster than --single.

Best regards,
--
Gurjeet Singh

http://gurjeet.singh.im/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavan Deolasee 2012-09-10 16:30:05 Re: pg_dump transaction's read-only mode
Previous Message Kevin Grittner 2012-09-10 16:15:31 Re: Question about SSI, subxacts, and aborted read-only xacts