Re: configuring timezone

> -----Original Message-----
> From: Adrian Klaver [mailto:adrian.klaver@gmail.com]
> Sent: Wednesday, February 06, 2013 4:40 PM
> To: Igor Neyman
> Cc: pgsql-general@postgresql.org
> Subject: Re: [GENERAL] configuring timezone
>=20
> On 02/06/2013 10:32 AM, Igor Neyman wrote:
> > Timezone configuration parameter (defaulting to system timezone)
> > worked fine for us before upgrading from 8.4. to 9.2.
> >
> > Now we've got a problem.
> >
> > 9.2 Release Notes says:
> >
> > *  Identify the server time zone during initdb, and set
> > postgresql.conf entries timezone
> > <http://www.postgresql.org/docs/9.2/static/runtime-config-
> client.html#
> > GUC-TIMEZONE>
> > and log_timezone
> > <http://www.postgresql.org/docs/9.2/static/runtime-config-
> logging.html
> > #GUC-LOG-TIMEZONE>
> > accordingly (Tom Lane)
> >
> > This avoids expensive time zone probes during server start.
> >
> > Question: is there any way to revert back to old behavior so that
> > server will probe system's timezone on startup (default to OS
> timezone
> > on
> > startup) instead setting it during initdb?
> >
> > Obviously, without recompiling/rebuilding Postgres.
> >
> > I'm dealing with the situation, where system is being built in one
> > timezone (could be anywhere around the globe), and then moved to
> other
> > (not known during system build) location with different timezone.
> >
> > After relocation, OS timezone will change, but we can't allow user to
> > edit timezone parameter in  Postgresql.conf.
>=20
>=20
> It is not possible to change the postgresql.conf just before the
> relocate? In other words do you have no idea where the server will end
> up?
>=20
> >
> > Regards,
> >
> > Igor Neyman
> >
>=20
>=20
> --
> Adrian Klaver
> adrian.klaver@gmail.com

Sometimes, but not always.

Going back to the reason for this change in Release Notes:

"This avoids expensive time zone probes during server start."

How expensive? How often Postgres is restarted?
We aren't restarting Postgres for months.  Doesn't seem to be very valid re=
ason, at least not for us :)

Igor Neyman