Re: Default timezone changes in 9.1

Поиск
Список
Период
Сортировка
От Robert Treat
Тема Re: Default timezone changes in 9.1
Дата
Msg-id CABV9wwN5QhHjqr7pv+798BZ5XTYYGAHh+kRM2YA1AMuu2sjeTA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Default timezone changes in 9.1  (Jasen Betts <jasen@xnet.co.nz>)
Список 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 по дате отправления:

Предыдущее
От: Michael Arnold
Дата:
Сообщение: Insert Assertion Failed in strcoll_l.c:112
Следующее
От: Florian Weimer
Дата:
Сообщение: Re: Pipelining INSERTs using libpq