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

Hi!

Andrew - Supernews [2005-06-10 23:29 -0000]:
> 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.

It was enabled ages ago; I can't tell you the reason since I have only
maintained the package for the last 1.5 years. But since then we had
to drag this setting to not break each and every database out there.
:-(

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

Maybe I did not express myself clearly: I don't ask to switch the
_database_ layout at runtime, but the postmaster behavior at startup
time. The idea: would be:

- Compile new versions with float timestamps (but with support for
integer timstamps, too).
- Create new clusters with float timestamps.
- If starting the postmaster on an already existing cluster fails
because of different timestamps (postmaster can detect this), start
the postmaster on the cluster with something like
"postmaster --integer-timestamps".

This would require that support for both int and float timestamps is
present in the postmaster, but wouldn't require an immediate dump and
reload of all databases. Would that be possible in any way?

If not, does anybody have any other idea?

Martin

--
Martin Pitt http://www.piware.de
Ubuntu Developer http://www.ubuntu.com
Debian Developer http://www.debian.org