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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: Alvaro Herrera <alvherre(at)2ndQuadrant(dot)com>, Amit kapila <amit(dot)kapila(at)huawei(dot)com>, Merlin Moncure <mmoncure(at)gmail(dot)com>, Gurjeet Singh <singh(dot)gurjeet(at)gmail(dot)com>, "hlinnaka(at)iki(dot)fi" <hlinnaka(at)iki(dot)fi>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Proof of concept: standalone backend with full FE/BE protocol
Date: 2012-11-13 20:16:16
Message-ID: 29170.1352837776@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
> On 13 November 2012 17:38, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2012-11-13 20:21:09 Re: Memory leaks in record_out and record_send
Previous Message Robert Haas 2012-11-13 20:11:02 Re: Memory leaks in record_out and record_send