Re: Yet another failure mode in pg_upgrade

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Magnus Hagander <magnus(at)hagander(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Yet another failure mode in pg_upgrade
Date: 2012-09-01 18:18:59
Message-ID: 19764.1346523539@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2012-09-01 18:23:22 Re: Yet another failure mode in pg_upgrade
Previous Message Robert Creager 2012-09-01 16:12:51 build farm machine using <make -j 8> mixed results