On Wed, Nov 20, 2013 at 05:38:14PM -0500, Gurjeet Singh wrote:
> On Wed, Nov 20, 2013 at 3:44 PM, Tom Lane <t...@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.

The magic cookie can be tha application_name.  I had pg_upgrade code to
prevent anyone from connecting unless their application_name was
"pg_upgrade", but the idea was rejected.

  Bruce Momjian  <br...@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + Everyone has their own god. +

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to