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: http://www.postgresql.org/mailpref/pgsql-hackers
