Re: Resurrecting pg_upgrade - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Resurrecting pg_upgrade
Date
Msg-id 21658.1071260800@sss.pgh.pa.us
Whole thread Raw
In response to Re: Resurrecting pg_upgrade  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
Peter Eisentraut <peter_e@gmx.net> writes:
> Tom Lane wrote:
>> Instead, all operations should be done through a standalone backend. 

> This would also be a nice solution for people who want a standalone, 
> server-less database system.  But for the purpose of pg_upgrade it 
> seems like a lot of work for what could just be a magic switch in the 
> postmaster to really kick everyone else out.

I don't think the approach I proposed is really materially harder than
convincing the postmaster to boot everyone else out.  (For one thing,
I'm not sure how the postmaster could reliably distinguish "you" from
"everyone else", bearing in mind that "you" will be needing to make
multiple connections to the old database.)  I also like the fact that
using a standalone backend dodges all issues about user permissions and
whether pg_hba.conf will let you connect to a particular database.

>> We could imagine adding smarts about specific variable names here,
>> if particular variables change in ways that we can deal with
>> specially.

> I would be very careful about making too many smart guesses when 
> upgrading configuration files.

Agreed.  That was more in the line of speculation than something
I wanted to do in the near term.  It does mean that people will
need to rein in the urge to rename configuration variables ;-)
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Marc G. Fournier"
Date:
Subject: Re: Resurrecting pg_upgrade
Next
From: Tom Lane
Date:
Subject: Re: Resurrecting pg_upgrade