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

Поиск
Список
Период
Сортировка
От Gurjeet Singh
Тема Re: Proof of concept: standalone backend with full FE/BE protocol
Дата
Msg-id CABwTF4VzgipbwvH6wsvaev3niN2jJd1z-G4+Bh2qW=-+w=ZrZw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Proof of concept: standalone backend with full FE/BE protocol  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Proof of concept: standalone backend with full FE/BE protocol  (Bruce Momjian <bruce@momjian.us>)
Список pgsql-hackers
On Wed, Nov 20, 2013 at 3:44 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

To my mind, the "create a socket and hope nobody else can get to it"
approach is exactly one of the main things we're trying to avoid here.
If you'll recall, awhile back we had a big discussion about how pg_upgrade
could positively guarantee that nobody messed with the source database
while it was working, and we still don't have a bulletproof guarantee
there.  I would like to fix that by making pg_upgrade use only standalone
backends to talk to the source database, never starting a real postmaster
at all.  But if the standalone-pg_dump mode goes through a socket, we're
back to square one on that concern.

(I couldn't find the pg_upgrade-related thread mentioned above).

I am not sure of the mechanics of this, but can we not launch the postmaster with a random magic-cookie, and use that cookie while initiating the connection from libpq. The postmaster will then reject any connections that don't provide the cookie.

We do something similar to enable applications to send cancellation signals (postmaster.c:Backend.cancel_key), just that it's establishing trust in the opposite direction.

Best regards,
--
Gurjeet Singh http://gurjeet.singh.im/

EnterprsieDB Inc. www.enterprisedb.com

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: additional json functionality
Следующее
От: Andrew Gierth
Дата:
Сообщение: Re: WITH ORDINALITY versus column definition lists