From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: timezone GUC |
Date: | 2011-05-19 16:14:28 |
Message-ID: | BANLkTi=pDg9Tuy+tfj3y4w80drWtjssgVQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, May 19, 2011 at 12:12 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> So I think you whacked this around some more to get a *somewhat* more
>> sensible behavior, but ISTM that the behavior here still not really
>> right. Should we select a timezone at startup time even if we don't
>> immediately need it, so that this can work correctly if we revert to
>> the default down the road?
>
> We could do that, but the issue that this code is trying to avoid is
> that identify_system_timezone can easily add several seconds to the
> postmaster startup time. So one of the reasons why someone would be
> putting a timezone setting into postgresql.conf in the first place is
> to not pay that startup overhead. I'm not thrilled with the idea
> of defeating that in order to cover the corner case where they remove
> the setting later.
Yeah, I'm not thrilled with that either. However, I'm also not
thrilled with the existing behavior. Consistency is the hobgoblin of
small minds, and also mine.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2011-05-19 16:15:15 | Re: Cannot build docs of 9.1 on Windows |
Previous Message | Robert Haas | 2011-05-19 16:12:25 | Re: patch: fix race in SSI's CheckTargetForConflictsIn |