Tom Lane [EMAIL PROTECTED] writes:
I don't think there is very much hope of an in-place upgrade for
scenarios involving changes in contents of user tables. In particular,
what of a change that requires more space than before, such as adding a
locale indicator to text fields? There's no
Martijn van Oosterhout kleptog@svana.org writes:
[ concerning handling a change in a single datatype's representation ]
1. Under old system, munge the system catalog to add code for new inet
type with new OID. Probably needs a shared lib (if you could create
type input/output function with
On Mon, Aug 07, 2006 at 08:37:14AM -0400, Tom Lane wrote:
Probably easier and more flexible just to include both versions of the
datatype in the new release, and tell people they'd better ALTER COLUMN
TYPE sometime before updating to release N+2.
Right, but I wasn't sure if that'd be
On Mon, Aug 07, 2006 at 06:05:30AM -0400, Gregory Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
I don't think there is very much hope of an in-place upgrade for
scenarios involving changes in contents of user tables. In particular,
what of a change that requires more space than before,
Hi,
[ concerning handling a change in a single datatype's representation ]
1. Under old system, munge the system catalog to add code for new inet
type with new OID. Probably needs a shared lib (if you could create
type input/output function with pl/pgsql it would help here).
2. Execute ALTER
Rick,
The objective is to smoothly upgrade to the new version with minimal
downtime.
Thanks for jumping in.
The different proposals as far as I can see are as follows:
Proposal A - the big one time reformatting
1) shutdown the db
2) run a command that upgrades the data directory to the
Josh Berkus josh@agliodbs.com writes:
Proposal C - PITR with in on the fly disk upgrades
1) setup PITR
2) run pg_upgrade on your latest backed up data directories
3) start up the new pg on that data directory in restartable
recovery / read-only / hot-standby mode
4) update the recovery log
* Jim C. Nasby ([EMAIL PROTECTED]) wrote:
On Thu, Aug 03, 2006 at 11:20:48PM -0700, Josh Berkus wrote:
* In-place upgrades (pg_upgrade)
BTW, I may get Sun to contribute an engineer for this; will get you posted.
How would such a thing handle changes to page formats?
Couldn't this be
On Fri, Aug 04, 2006 at 02:12:16PM -0400, Stephen Frost wrote:
* Jim C. Nasby ([EMAIL PROTECTED]) wrote:
On Thu, Aug 03, 2006 at 11:20:48PM -0700, Josh Berkus wrote:
* In-place upgrades (pg_upgrade)
BTW, I may get Sun to contribute an engineer for this; will get you
posted.
* Jim C. Nasby ([EMAIL PROTECTED]) wrote:
On Fri, Aug 04, 2006 at 02:12:16PM -0400, Stephen Frost wrote:
* Jim C. Nasby ([EMAIL PROTECTED]) wrote:
How would such a thing handle changes to page formats?
Couldn't this be done by converting a table/partial-table at a time?
It wouldn't be
I had a few thoughts on this issue:
The objective is to smoothly upgrade to the new version with minimal
downtime.
The different proposals as far as I can see are as follows:
Proposal A - the big one time reformatting
1) shutdown the db
2) run a command that upgrades the data directory to
11 matches
Mail list logo
