Re: Bug#311533: Invalid timestamp returned because of timezone

From: Andrew - Supernews <andrew+nonews(at)supernews(dot)com>
To: pgsql-bugs(at)postgresql(dot)org
Subject: Re: Bug#311533: Invalid timestamp returned because of timezone
Date: 2005-06-10 23:29:41
Message-ID: slrndak8j5.2799.andrew+nonews@trinity.supernews.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On 2005-06-10, Martin Pitt <martin(at)piware(dot)de> wrote:
>> As per conversation in #postgresql in freenode, it has been found that
>> this seems to manifest on pgsql compiled using integer-datetime;
>> float-datetime version does not have this problem.
>
> I just tried to do the proposed change, however, it is not possible to
> start the new postmaster on an already existing cluster. You had to
> dump all clusters with the old postmaster, install the new one and
> recreate the clusters, which is a hell of an upgrade (so it's
> definitively nothing for Sarge, even less for sarge-proposed updates).
> So I can't apply that change for now.

Out of curiosity, why was it using the integer-datetimes option at all?
It's not the default in the distributed source, and it's had a series of
bugs found in it, this being merely the latest.

> The cleanest one would obviously be to fix integer timestamps, or if
> that is not possible, at least support selecting integer or float time
> stamps at runtime (maybe as a postmaster option). Can this be done in
> any way?

Since changing the option affects how every single timestamp value in the
database is stored, it's hard to see how it could be made switchable at
runtime.

--
Andrew, Supernews
http://www.supernews.com - individual and corporate NNTP services

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Dan Jacobson 2005-06-11 01:50:50 could not connect to server: [then mess]
Previous Message steve owen 2005-06-10 17:32:32 BUG #1716: FATAL: XX000: failed to initialize lc_messages to ""