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

On 14 November 2013 03:41, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:

> I have gone through the mail chain of this thread and tried to find
> the different concerns or open ends for this patch.

Not enough. This feature is clearly being suggested as a way to offer
Postgres in embedded mode for users by a back door. Doing that forces
us to turn off many of the server's features and we will take a huge
step backwards in features, testing, maintainability of code and
wasted community time.

"No administrative hassles" is just a complete fiction. Admin will
become a huge burden for any user in this mode, which will bite the
community and cause us to waste much time redesigning the server to
operate on a single session.

-1 from me

> 4. Secondary connections for data access
>
> Proposal
> ---------------
> A single-user connection database with "no administrative hassles"
>
> Concerns
> -----------------
> As this proposal will not allow any data it stores to 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.
>
> Suggestions for it's use or make it usable
> ----------------------------------------------------------------
> a. a usable & scriptable --single mode is justification enough.
> Having to wait for hours just enter one more command because --single
> doesn't support any scripts sucks. Especially in
> recovery situations.
> b. it's worth having this particular thing because it makes
> pg_upgrade more robust.
> c. some competing solutions already provide similar solution
> (http://www.firebirdsql.org/manual/fbmetasecur-embedded.html).
> d. we need to make sure that this isn't foreclosing the option of
> having a multi-process environment with a single user connection. I
> don't see that it is, but it might be wise to sketch
> exactly how that case would work before accepting this.

Why is not feasible to run a normal server with 1 connection.

Are we really following what Firebird is doing? Why?

> 6. Restricting operation's in single backend mode
>
> Serializable transactions could skip all the SSI predicate locking
> and conflict checking when in single-connection mode. With only one
> connection the transactions could never overlap, so
> there would be no chance of serialization anomalies when running
> snapshot isolation.
>
> It could be of use if someone had code they wanted to run under
> both normal and single-connection modes. For single-connection only,
> they could just choose REPEATABLE READ to
> get exactly the same semantics.

This is an example of my concern that we would begin optimising for
the case of single user mode and encourage its use by users. This
shows that the feature is not being suggested just for recovery.

PostgreSQL has been designed from the ground up to support
concurrency. If we begin optimising for single user mode it will take
years to unpick our work and eventually we'll have a conflict and
someone will say "we can't do that because it will be a problem in
single user mode".

> 7. Proposal related to maintainence activities
>
> For maintainence activities, in longer run, we can have a
> postmaster process that isn't listening on any ports, but is managing
> background processes in addition to a single child backend.
>
> As per my understanding, to complete this patch we need to
> a. complete the work for #1, #2, #5
> b. #6 and #7 can be done as enhancements after the initial feature is committed
> c. need to decide what should we do for #3 and #4.

Huh? Multi-process mode already works. Why would do we need "a
solution" for the problem that single process mode uses only one
process? Don't use it.

--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services