Re: walprotocol.h vs frontends

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Peter Geoghegan <peter(at)2ndquadrant(dot)com>
Cc: Steve Singer <ssinger(at)ca(dot)afilias(dot)info>, Magnus Hagander <magnus(at)hagander(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Johann 'Myrkraverk' Oskarsson <johann(at)2ndquadrant(dot)com>
Subject: Re: walprotocol.h vs frontends
Date: 2011-08-16 08:41:41
Message-ID: 1313484101.5935.6.camel@vanquo.pezone.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On mån, 2011-08-15 at 18:39 +0100, Peter Geoghegan wrote:
> > If you want to upgrade a system running 8.3 (that uses float based
> timestamps) in using
> > pg_upgrade you must compile 9.0 (or 8.4 or 9.1) with
> > --disable-integer-datetimes. If at some point in the future you
> then want
> > to upgrade to 9.2 with pg_upgrade you will again need to build 9.2
> with
> > --disable-integer-datetimes. If we remove the code for floating
> point
> > representations of datetime then you won't be able to do that.
>
> I'm pretty surprised that pg_upgrade pushes that onus onto its users -
> for many users, the need to build their own binaries is a greater
> barrier to upgrading than doing a logical restore. Maybe that's simply
> considered a matter for package managers to worry about, but that
> doesn't sit well with me.

Well, pg_upgrade only moves the heap files, it doesn't look into them or
change them.

Possibly, this sort of issue could be better handled in the future by
making this a cluster, database, or table flag instead of a compile-time
option. That way, at least newly created things could move to the new
recommended behavior. The way it is set up now, we will possibly never
get rid of the legacy behavior, unless we break pg_upgrade at some
point.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2011-08-16 08:55:49 Some problems about cascading replication
Previous Message Magnus Hagander 2011-08-16 08:38:08 Re: some missing internationalization in pg_basebackup