Re: Yet another failure mode in pg_upgrade - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Yet another failure mode in pg_upgrade
Date
Msg-id 19764.1346523539@sss.pgh.pa.us
Whole thread Raw
In response to Re: Yet another failure mode in pg_upgrade  (Bruce Momjian <bruce@momjian.us>)
Responses Re: Yet another failure mode in pg_upgrade  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
Bruce Momjian <bruce@momjian.us> writes:
> On Sat, Sep  1, 2012 at 11:45:58AM -0400, Bruce Momjian wrote:
>> So, in summary, this patch moves the socket directory to the current
>> directory all but live check operation, and handles different socket
>> directories for old cluster >= 9.1.  I have added a documentation
>> mention of how to make this work for for pre-9.1 old servers.
>> 
>> Thus completes another "surgery on a moving train" that is pg_upgrade
>> development.

> Oh, one more thing.  We have talked about creating some special pipe for
> pg_upgrade to communicate the a backend directly, but live check mode
> hightlights that we will _still_ need traditional connection abilities
> even if we add the pipe ability.

So?  By definition, the live check mode is not guaranteed to produce
correct answers, since other connections could be changing the
database's contents.  The problem we are interested in solving here is
preventing other connections from occurring when we're doing the upgrade
"for real".  All this stuff with moving sockets around is nothing but
security by obscurity; it cannot positively guarantee that there's
nobody else connecting to the database while pg_upgrade runs.  (Most
notably, on Windows there's no guarantee at all.)
        regards, tom lane



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Yet another failure mode in pg_upgrade
Next
From: Tom Lane
Date:
Subject: Re: Yet another failure mode in pg_upgrade