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

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Merlin Moncure <mmoncure(at)gmail(dot)com>, Gurjeet Singh <singh(dot)gurjeet(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Proof of concept: standalone backend with full FE/BE protocol
Date: 2013-12-06 16:18:48
Message-ID: 20131206161848.GA17222@awork2.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2013-12-06 11:02:48 -0500, Tom Lane wrote:
> Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> My feeling is that we should just treat the executable name and data
> directory path as new connection parameters, which'd be ignored in
> normal-connection mode, just as some other parameters will be ignored in
> single-user mode. Otherwise we'll find ourselves building parameter
> setting infrastructure that pretty much duplicates what's there for the
> existing connection parameters.

Right.

> I think the special-purpose command line switches you mention can be
> passed through PGOPTIONS, rather than inventing a new parameter -- do you
> have an objection to that?

I am not sure if they currently will get recognized early enough and
whether permission checking will interferes, but if so, that's probably
fixable.

> > Not sure if we need anything but the pid of the postmaster be returned?
>
> The new PQconnect routine would certainly hand back a PGconn. I think
> we'd need a new query function PQchildPid(PGconn *) or some such to
> provide access to the child process PID.

I was thinking of a pid_t* argument to the new routine, but it's likely
unneccessary as we're probably going to end up storing it in PGconn
anyway.

There's the question what we're going to end up doing with the current
single user mode? There's some somewhat ugly code around for it...

Greetings,

Andres Freund

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2013-12-06 16:27:17 Re: Proof of concept: standalone backend with full FE/BE protocol
Previous Message Peter Eisentraut 2013-12-06 16:14:14 commit fest 2013-11 week 3 report