Re: Resurrecting pg_upgrade

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Resurrecting pg_upgrade
Date: 2003-12-12 20:26:40
Message-ID: 21658.1071260800@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut <peter_e(at)gmx(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2003-12-12 20:31:44 Re: Resurrecting pg_upgrade
Previous Message Marc G. Fournier 2003-12-12 20:24:00 Re: Resurrecting pg_upgrade