Re: timezone GUC

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: timezone GUC
Date: 2011-09-06 21:16:58
Message-ID: 22214.1315343818@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> I am (and, I think, Alvaro is also) of the opinion that the behavior
>> here is still not really right.

> I don't see a practical way to do better unless we can find a less
> horridly inefficient way of implementing identify_system_timezone().

Although there's always more than one way to skin a cat. Consider
this idea:

1. The hard-wired default for timezone is always UTC (or something
else not dependent on environment).

2. We put the identify_system_timezone work into initdb, and have it
inject a non-default entry into postgresql.conf in the usual way
if it can identify what the system zone is.

3. Run-time dependency on TZ environment disappears altogether.

This basically means that instead of incurring that search on every
postmaster start, we do it once at initdb. If you change the
postmaster's timezone environment, well, you gotta go change
postgresql.conf.

IMO this would be less DBA-friendly in practice, but only very
marginally so; and getting rid of the special initialization behavior of
the timezone GUC might well be considered sufficient recompense.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2011-09-06 21:23:20 Re: getting carriage return character in vacuumo
Previous Message Robert Haas 2011-09-06 21:03:30 Re: [PATCH] Log crashed backend's query (activity string)