Re: Yet another failure mode in pg_upgrade

On Sat, Sep 1, 2012 at 02:18:59PM -0400, Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +