Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
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


pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group