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
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 tha
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 conside
Martijn van Oosterhout 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 pl/pgsql it woul
On Mon, Aug 07, 2006 at 06:05:30AM -0400, Gregory Stark wrote:
> What of having support in the backend for two heap formats in each version.
> That is, 8.3 would be able to support 8.2 heaps as well as 8.3. There could be
> a flag in pg_class indicating the heap format for that heap. Then you would
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
Josh Berkus 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 importe
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
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 th
* 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
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
> >
* 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
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?
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECT
13 matches
Mail list logo
