Re: Proof of concept: standalone backend with full FE/BE protocol - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Proof of concept: standalone backend with full FE/BE protocol
Date
Msg-id 29170.1352837776@sss.pgh.pa.us
Whole thread Raw
In response to Re: Proof of concept: standalone backend with full FE/BE protocol  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: Proof of concept: standalone backend with full FE/BE protocol  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
List pgsql-hackers
Simon Riggs <simon@2ndQuadrant.com> writes:
> On 13 November 2012 17:38, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> ...  The fact of the matter is that there is *lots* of demand
>> for simple single-user databases, and what I'm proposing is at least a
>> first step towards getting there.

> I agree there is lots of demand for simple single-user databases and I
> wish that too. What I don't agree with is something that casts that
> requirement in stone by architecturally/permanently disallowing
> secondary connections.

If you want secondary connections, then I think you want a postmaster.
We already have umpteen ways to limit who can connect (for example,
putting the socket in a directory with limited access rights), and in
that sort of situation I don't see why you'd really want a database
that is only accessible when the "main" client is running.

The case that this patch is meant to address is one where there is only
one client application, period, and you'd rather that the database
starts and stops automatically with that application instead of needing
any management complexity.  Now we can debate whether we want only one
process or multiple processes underneath the client application, but
I think the restriction to one client connection is a key *feature*
not a bug, precisely because it removes a whole bunch of user-visible
complexity that we cannot escape otherwise.

> People are migrating away from embedded databases in droves for these
> very reasons.

[ shrug... ]  If they don't want an embedded database, they won't want
this either, but there are still plenty of people left who do want an
embedded database.  We've never had an adequate offering for those
people before.  If we ratchet up the management complexity of "single
user" mode then it still won't be an adequate offering for them.

> I see this decision as a critical point for this project, so please
> consider this objection and where it comes from.

I think this is nonsense.  It's not critical; it's a very small patch
that provides a feature of interest to a limited audience.  And I don't
believe it's foreclosing providing other operating modes later, unless
maybe people feel this is "almost good enough" and lose motivation to
work on those other operating modes.  But if that happens, then I'd say
the demand for the other modes isn't as high as you think.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Memory leaks in record_out and record_send
Next
From: Tom Lane
Date:
Subject: Re: Memory leaks in record_out and record_send