| From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, simon(at)2ndquadrant(dot)com, Merlin Moncure <mmoncure(at)gmail(dot)com>, Gurjeet Singh <singh(dot)gurjeet(at)gmail(dot)com>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Robert Haas <robertmhaas(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-11-20 20:21:21 |
| Message-ID: | 528D19C1.9050808@gmx.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 11/20/13, 10:48 AM, Tom Lane wrote:
> Perhaps more to the point, I think this approach actually breaks one of
> the principal good-thing-in-emergencies attributes of standalone mode,
> namely being sure that nobody but you can connect. With this, you're
> right back to having a race condition as to whether your psql command
> gets to the socket before somebody else.
I don't disagree, except maybe about the relative gravity of the various
competing concerns. But I want to see if we can split the proposed
patch into smaller, more acceptable parts.
There is elegance in being able to start a standalone backend from libpq
connection parameters. But there are also security concerns and some
general concerns about promoting an embedded database mode.
If we allow single-user backends to speak protocol over sockets, then we
have at least solved the problem of being able to use standard tools in
emergency mode. And I don't think it precludes adding some of the other
functionality later.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2013-11-20 20:24:52 | Re: Proof of concept: standalone backend with full FE/BE protocol |
| Previous Message | Alexander Korotkov | 2013-11-20 20:14:11 | Re: GIN improvements part2: fast scan |