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

From Merlin Moncure
Subject Re: Proof of concept: standalone backend with full FE/BE protocol
Date
Msg-id CAHyXU0yu4wNgRL2+fEEf4s3qF5HCNa9mdZfff8xYCgpz4-LzoQ@mail.gmail.com
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  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
On Mon, Nov 12, 2012 at 1:21 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> On 10 September 2012 17:50, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
>> The point of the proposal that I am making is to have a simple,
>> low-maintenance solution for people who need a single-application
>> database.  A compromise somewhere in the middle isn't likely to be an
>> improvement for anybody.  For instance, if you want to have additional
>> connections, you open up a whole collection of communication and
>> authentication issues, which potential users of a single-application
>> database don't want to cope with.
>
> So the proposal is to implement a database that can't ever have 2 or
> more connections. And so any data it stores cannot ever be accessed by
> another connection, so all forms of replication are excluded and all
> maintenance actions force the database to be unavailable for a period
> of time. Those two things are barriers of the most major kind to
> anybody working in an enterprise with connected data and devices. The
> only people that want this are people with a very short term view of
> the purpose of their applications, and disregard for the value and
> permanence of the data stored. They may not want to cope with those
> issues *now* but they will later and won't thank us for implementing
> it in a way that means it can never be achieved.
>
> To be honest, I can't believe I'm reading this.
>
> And worse, it's on our Don't Want list, and nobody has said stop.
>
> It's almost impossible to purchase a CPU these days that doesn't have
> multiple cores, so the whole single-process architecture is just dead.
> Yes, we want Postgres installed everywhere, but this isn't the way to
> achieve that.
>
> I agree we should allow a PostgreSQL installation to work for a single
> user, but I don't see that requires other changes. This idea will
> cause endless bugs, thinkos and severely waste our time. So without a
> much better justification, I don't think we should do this.

I couldn't disagree more.  The patch is small, logical, and fixes an
awful problem, namely that --single mode is basically unusable.  As to
your wider point (namely, that you can't connect to it, therefore it's
bad), it has got to be refuted by numerous competing solutions in the
market such as http://www.firebirdsql.org/manual/fbmetasecur-embedded.html,
and many others.

While it's not as common as it used to be, now and then a piece of
software needs to distribute an application as part of a boxed
product.  Postgres is horrible at this and doesn't have to be; imagine
how much easier the lives of poker tracker would be (for *some* of its
users) with an integrated standalone mode: google 'poker tracker
postgresql' and take a good long look at problems people face in this
scenario.

merlin



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Further pg_upgrade analysis for many tables
Next
From: Bruce Momjian
Date:
Subject: Re: Further pg_upgrade analysis for many tables