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

From Dimitri Fontaine
Subject Re: Proof of concept: standalone backend with full FE/BE protocol
Date
Msg-id m28va5runz.fsf@2ndQuadrant.fr
Whole thread Raw
In response to Re: Proof of concept: standalone backend with full FE/BE protocol  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.us> writes:
>> 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.

I would agree. I think you're both talking above each other, and that
what Simon is worried about (but I haven't asked him about that before
sending that email) is how to change the application setup to switch
from single user mode to multi user mode.

IIRC the way to implement single user mode in your application is quite
low-level with this patch, so switching to multi-user mode is not about
just changing the connection string, or is it?

> 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.

Well I think your patch would be easier to accept as is if it was
documented only as a psql friendly single-user mode. I would really
welcome that.

> 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.

Now, if we're talking about single user mode as in embedded database, I
really do think this patch should include a solution to run online
maintainance, logical and physical backups, replication, archiving and
all the production grade features you expect from PostgreSQL.

And then I understand Simon's POV about code complexity and bgworkers
for examples, which will *need* to be taken care of in that solution.

> 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

Yes, it's providing full psql capabilities where we only had that bizare
postgres --single interface. Maybe it will make initdb and debugging it
easier too.

> 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.

Again, my concern on that point after reading Simon's comments is only
about the production procedure you have to follow to switch your
application from single user mode to multi user mode.

Regards,
-- 
Dimitri Fontaine
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support



pgsql-hackers by date:

Previous
From: Jehan-Guillaume de Rorthais
Date:
Subject: Process waiting for ExclusiveLock on INSERT
Next
From: Peter Geoghegan
Date:
Subject: Re: Index only scans wiki page