Re: Upgrading rant.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Hannu Krosing <hannu(at)tm(dot)ee>, mlw <pgsql(at)mohawksoft(dot)com>, Lamar Owen <lamar(dot)owen(at)wgcr(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Upgrading rant.
Date: 2003-01-04 02:17:39
Message-ID: 24133.1041646659@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> Is pg_upgrade too hard to run?

It is hard and dangerous to run (IMHO). One thing I would like to see
that would make it much safer to run is to recast it to operate through
standalone backends. That is, the idea is

bring down old postmaster

install new version

run new version's pg_upgrade
-- all work done without a postmaster

start new postmaster

It's much harder to get this wrong than it is to mess up with the
current situation (where pg_upgrade talks to live postmasters).
There isn't any simple way to lock *everyone* out of the DB and still
allow pg_upgrade to connect via the postmaster, and even if there were,
the DBA could too easily forget to do it.

This would require a nontrivial amount of work (notably, we'd have to
be able to get pg_dump to run against a standalone backend) but I don't
think I'd trust pg_upgrade as a production-grade tool until its
invocation method looks like the above.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Copeland 2003-01-04 03:38:46 Re: Threads
Previous Message Greg Copeland 2003-01-04 02:11:17 Re: Threads