From: | Steve Singer <ssinger(at)ca(dot)afilias(dot)info> |
---|---|
To: | Peter Geoghegan <peter(at)2ndquadrant(dot)com> |
Cc: | 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-15 17:09:33 |
Message-ID: | 4E4952CD.5000508@ca.afilias.info |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 11-08-15 12:33 PM, Peter Geoghegan wrote:
> On 15 August 2011 16:56, Steve Singer<ssinger(at)ca(dot)afilias(dot)info> wrote:
>> This would mean that anyone using the floating point timestamps today won't
>> be able to use pg_upgrade to upgrade to whichever version we remove them
>> from. 8.3 had float based timestamps as the default and I suspect many
>> installations with the default 8.3 settings have been upgraded via
>> pg_upgrade to 9.0 built the old timestamps representation.
>
> Really? I find that slightly surprising, considering that a quick look
> at master's timestamp.c suggests that the choice to use the in64
> representation over the double representation is entirely a case of
> compile time either/or. There is no apparent fall-back to the double
> representation available to binaries built without
> --disable-integer-datetimes.
>
I *think* the default on 8.3 was float based timestamps. 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.
Steve
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2011-08-15 17:27:03 | Re: walprotocol.h vs frontends |
Previous Message | Kevin Grittner | 2011-08-15 17:06:29 | Re: our buffer replacement strategy is kind of lame |