Re: New tzdata available

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM>
Cc: Alvaro Herrera <alvherre(at)CommandPrompt(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Devrim GÜNDÜZ <devrim(at)CommandPrompt(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: New tzdata available
Date: 2007-11-09 13:28:08
Message-ID: 1194614888.6742.12.camel@mha-laptop.clients.sollentuna.se
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On Fri, 2007-11-09 at 14:23 +0100, Zdenek Kotala wrote:
> Magnus Hagander wrote:
> > On Fri, 2007-11-09 at 09:25 -0300, Alvaro Herrera wrote:
> >> Magnus Hagander wrote:
> >>> Tom Lane wrote:
> >>>> Alvaro Herrera <alvherre(at)CommandPrompt(dot)com> writes:
> >>>>> Zdenek Kotala wrote:
> >>>>>> I think we need some different mechanism how to deliver timezone updated.
> >>>>> Even when the system TZ is not used, we could deliver our "zic"
> >>>>> executable (pgzic?) and let the user drop the latest tzdata somewhere
> >>>>> and recompile it.
> >>>> Well, a person who builds from source has already got the zic program;
> >>>> all we need do is document someplace (more visible than now) how to drop
> >>>> the tzdata update into the source tree and reinstall the files.
> >>>>
> >>>> For people using prebuilt packages, it's really the packager's problem.
> >>>> I think most packagers are going to move to depending on a system
> >>>> timezone DB if at all possible.
> >>> Still need a solution for those where it's not possible (hint: Windows).
> >>> Not saying it has to be what's there now, but there has to be something
> >>> workable.
> >> I think the first step is to install the zic binary along the rest of
> >> the stuff, so that a user without the source tree can compile the tzdata
> >> package. Unless the compiled representation is portable, which I kinda
> >> doubt?
> >
> > At least they're not guaranteed to be. So yeah, we could ship the zic
> > binary and instructions on how to update the files, or we could ship the
> > files themselves.
> >
> > A big question is, are any platforms *other* than Windows really doing
> > this? Or do all other platforms use the system TZ data? If it's just
> > Windows, then we're probably better off just shipping a ZIP file with
> > it, since that'll be the easiest for the user... And building just that
> > ZIP file should be a *lot* easier than building a full release package.
>
> In 8.3 you have configure option, but for 8.0-8.2 branches you must make
> some extra magic to integrate postgres with system timezone files. How
> Tom mentioned for packager it is OK, but for users who want to compile
> postgres 8.0-8.2 by them self is little bit complicated.
>
> Another interesting questions are what postgres does when timezone files
> are changed? Does it need SIGHUP to invoke rereading? What is impact on
> current running transaction when tz file is changed?

That won't happen. The first time a timezone is loaded, it's cached. If
this happens in the postmaster, it'll be inherited by children. If it
happens in the backend, it'll still be used until that backend exits. So
there is no way for the TZ information to change on anything currently
running. But to make sure everything is updated, you need to restart the
whole cluster.

The one thing you have there is that if you have two related timezone
updates - you can theoretically notice one change and not the other,
since the replacement isn't atomic. But I really can't get excited about
that one.

//Magnus

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2007-11-09 13:45:52 Re: Free Space Map thoughts
Previous Message Heikki Linnakangas 2007-11-09 13:27:10 Re: Free Space Map thoughts