On Sat, Dec 22, 2012 at 3:41 AM, Jasen Betts wrote:
> On 2012-12-16, Terence Ferraro 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 s
On 2012-12-16, Terence Ferraro 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 a
On Sun, Dec 16, 2012 at 1:16 PM, Tom Lane wrote:
> Andres Freund writes:
> > On 2012-12-16 12:25:13 -0500, Tom Lane wrote:
> >> I'm still not sure what
> >> the OP actually wants to accomplish by moving the time of making the
> >> choice.
>
> > I guess he wants - and I have seen that before - to
Andres Freund writes:
> On 2012-12-16 12:25:13 -0500, Tom Lane wrote:
>> I'm still not sure what
>> the OP actually wants to accomplish by moving the time of making the
>> choice.
> I guess he wants - and I have seen that before - to use the same
> postgresql.conf across a number of different sys
On 2012-12-16 12:25:13 -0500, Tom Lane wrote:
> Andres Freund writes:
> > Setting the timezone to 'localtime' seems to work as well, even without
> > a patch. I haven't found any documentation about it and I am not
> > completely sure about the semantics, but it looks ok on a first glance.
>
> I t
Andres Freund writes:
> Setting the timezone to 'localtime' seems to work as well, even without
> a patch. I haven't found any documentation about it and I am not
> completely sure about the semantics, but it looks ok on a first glance.
I think on most distros that use the Olson tz database, 'loc
Terence Ferraro writes:
> Post 9.1, the system determines this via initdb data directory
> initialization and automatically sets it within postgresql.conf.
> In other words, the default now is *not* GMT but rather the system detected
> timezone at initdb runtime. Removing that statically set confi
Hi,
On 2012-12-15 22:07:32 -0500, Terence Ferraro wrote:
> We recently began upgrading our clients' servers from 9.0 -> 9.2. After a
> few deployments and a little digging we noticed that 9.0 -> 9.1 broke the
> use of no timezone set within postgresql.conf. That is, not setting the
> option was no
On 16/12/12 18:23, Terence Ferraro wrote:
On Sat, Dec 15, 2012 at 11:54 PM, Gavin Flower
mailto:gavinflo...@archidevsys.co.nz>>
wrote:
Please do not top post, see end of email for rest of reply...
(Bottom posting is the convention here, so people can see the
context before readin
On Sat, Dec 15, 2012 at 11:54 PM, Gavin Flower <
gavinflo...@archidevsys.co.nz> wrote:
> Please do not top post, see end of email for rest of reply...
> (Bottom posting is the convention here, so people can see the context
> before reading your reply.)
>
>
>
> On 16/12/12 16:52, Terence Ferraro w
Please do not top post, see end of email for rest of reply...
(Bottom posting is the convention here, so people can see the context
before reading your reply.)
On 16/12/12 16:52, Terence Ferraro wrote:
Sorry about the double post, I thought the list disallowed attachments
so I sent it again w
Sorry about the double post, I thought the list disallowed attachments so I
sent it again with a pastebin link instead of an attachment.
This change does not affect the storage at all. If it did, pre-9.1 things
would have been a mess. Rather, this allows the system to determine the
timezone for lo
On 16/12/12 16:07, Terence Ferraro wrote:
We recently began upgrading our clients' servers from 9.0 -> 9.2.
After a few deployments and a little digging we noticed that 9.0 ->
9.1 broke the use of no timezone set within postgresql.conf. That is,
not setting the option was now defaulting to GMT
13 matches
Mail list logo
