Re: walprotocol.h vs frontends

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

In response to

Responses

Browse pgsql-hackers by date

  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