Re: walprotocol.h vs frontends - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: walprotocol.h vs frontends
Date
Msg-id CAEYLb_XVAD-eQmF2W0H2GgrvXoVdzXHkcpt1jiNhp4Dr1_aqYA@mail.gmail.com
Whole thread Raw
In response to Re: walprotocol.h vs frontends  (Steve Singer <ssinger@ca.afilias.info>)
Responses Re: walprotocol.h vs frontends
List pgsql-hackers
On 15 August 2011 18:09, Steve Singer <ssinger@ca.afilias.info> wrote:
>> 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.

Yes, it is.

> 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.

--
Peter Geoghegan       http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: walprotocol.h vs frontends
Next
From: Simon Riggs
Date:
Subject: Re: walprotocol.h vs frontends