From: | Amit Kapila <amit(dot)kapila(at)huawei(dot)com> |
---|---|
To: | "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "'Robert Haas'" <robertmhaas(at)gmail(dot)com> |
Cc: | "'Alvaro Herrera'" <alvherre(at)commandprompt(dot)com>, "'Peter Eisentraut'" <peter_e(at)gmx(dot)net>, "'Pg Hackers'" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: new --maintenance-db options |
Date: | 2012-06-26 06:14:53 |
Message-ID: | 002201cd5363$00caf0a0$0260d1e0$@kapila@huawei.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
From: pgsql-hackers-owner(at)postgresql(dot)org
[mailto:pgsql-hackers-owner(at)postgresql(dot)org] On Behalf Of Tom Lane
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> From pg_upgrade's perspective, it would
>> be nice to have a flag that starts the server in some mode where
>> nobody but pg_upgrade can connect to it and all connections are
>> automatically allowed, but it's not exactly clear how to implement
>> "nobody but pg_upgrade can connect to it".
> The implementation I've wanted to see for some time is that you can
> start a standalone backend, but it speaks FE/BE protocol to its caller
> (preferably over pipes, so that there is no issue whatsoever of where
> you can securely put a socket or anything like that).
Can't it be done like follow the FE/BE protocol, but call directly the
server API's
at required places.
This kind of implementation can be more performant than adding any
communication to it which will be
beneficial for embedded databases.
> Making that
> happen might be a bit too much work if pg_upgrade were the only use
> case, but there are a lot of people who would like to use PG as an
> embedded database, and this might be close enough for such use-cases.
Seeing PG to run as embedded database would be interesting for many people
using PG.
There is another use case of embedded databases that they allow another
remote connections
as well to monitor the operations in database. However that can be done in a
later version of implementation.
With Regards,
Amit Kapila.
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2012-06-26 07:20:38 | Re: proof concept - access to session variables on client side |
Previous Message | Pavel Stehule | 2012-06-26 05:06:06 | proof concept - access to session variables on client side |