Re: Default timezone changes in 9.1 - Mailing list pgsql-general

From Robert Treat
Subject Re: Default timezone changes in 9.1
Date
Msg-id CABV9wwN5QhHjqr7pv+798BZ5XTYYGAHh+kRM2YA1AMuu2sjeTA@mail.gmail.com
Whole thread Raw
In response to Re: Default timezone changes in 9.1  (Jasen Betts <jasen@xnet.co.nz>)
List pgsql-general
On Sat, Dec 22, 2012 at 3:41 AM, Jasen Betts <jasen@xnet.co.nz> wrote:
> On 2012-12-16, Terence Ferraro <terencejferraro@gmail.com> wrote:
>
>> With the exception of a few parameters (max_connections and the ssl related
>> variables that we enable), the default configuration file (circa 9.0) has
>> worked extremely well across 100+ machines so far over the last two years
>> and counting. However, we are simply deploying these on commodity machines
>> ($300-400 off the shelf). Spec wise such machines have not changed
>> significantly (I suppose the shift away from higher clock speeds to more
>> cores can be thanked for that).
>
> You cam possibly get some of what you want using "SQL" like:
>
>  alter database "DB_NAME" set timezone = 'localtime';
>
>  You can do the similarly with other connection parameters on a
> per-user or per-database basis too.
>

If the goal is just to use a single config and have tz match the
system, the setting localtime in the postgresql.conf should suffice.
IIRC this is what we've started doing, since we we're bit by this as
well. (I think the first systems we noticed it on were ones where
system was UTC and Postgres was GMT, which was mostly a cosmetic
problem, but it surprised us elsewhere too). It makes me wonder if
there was enough thought put into the backwards compatibility angle of
this; either what the default should be, or to make sure people were
aware of the change.

Robert Treat
play: xzilla.net
work: omniti.com


pgsql-general by date:

Previous
From: Michael Arnold
Date:
Subject: Insert Assertion Failed in strcoll_l.c:112
Next
From: Florian Weimer
Date:
Subject: Re: Pipelining INSERTs using libpq