Re: Yet another failure mode in pg_upgrade

On Sat, Sep  1, 2012 at 02:18:59PM -0400, Tom Lane wrote:
> 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

True.

> 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.)

My point is that we are still going to need traditional connections for
live checks.  If we could find a solution for Windows, the socket in
current directory might be enough to lock things down, especially if we
put the socket in a new subdirectory that only we can read/write to. 
Should I persue that in my patch?

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +