Peter Eisentraut writes:
> It looks like the --with-system-tzdata case is somewhat broken now in
> initdb:
> creating configuration files ... could not open directory
> "./pg-install/share/timezone": No such file or directory
Sigh. That's what I get for assuming that case was simple enough
On ons, 2011-09-07 at 17:16 -0400, Tom Lane wrote:
> Magnus Hagander writes:
> > On Tue, Sep 6, 2011 at 23:52, Robert Haas wrote:
> >> On Tue, Sep 6, 2011 at 5:16 PM, Tom Lane wrote:
> >>> Although there's always more than one way to skin a cat. Consider
> >>> this idea:
> >>>
> >>> 1. The hard
Magnus Hagander writes:
> On Tue, Sep 6, 2011 at 23:52, Robert Haas wrote:
>> On Tue, Sep 6, 2011 at 5:16 PM, Tom Lane wrote:
>>> 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
On Tue, Sep 6, 2011 at 23:52, Robert Haas wrote:
> On Tue, Sep 6, 2011 at 5:16 PM, Tom Lane wrote:
>> I wrote:
>>> Robert Haas 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 un
On Tue, Sep 6, 2011 at 5:16 PM, Tom Lane wrote:
> I wrote:
>> Robert Haas 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 imp
I wrote:
> Robert Haas 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 a
Robert Haas writes:
> On Tue, Sep 6, 2011 at 3:31 PM, Tom Lane wrote:
>> Bruce Momjian writes:
>>> Was this dealt with?
>> Yes, as much as I think is reasonable anyway. See
>> commit e05b866447899211a0c2df31bf0671faac4fc3e5.
> I am (and, I think, Alvaro is also) of the opinion that the behavi
On Tue, Sep 6, 2011 at 3:31 PM, Tom Lane wrote:
> Bruce Momjian writes:
>> Was this dealt with?
>
> Yes, as much as I think is reasonable anyway. See
> commit e05b866447899211a0c2df31bf0671faac4fc3e5.
I am (and, I think, Alvaro is also) of the opinion that the behavior
here is still not really
Bruce Momjian writes:
> Was this dealt with?
Yes, as much as I think is reasonable anyway. See
commit e05b866447899211a0c2df31bf0671faac4fc3e5.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Tom Lane wrote:
> Robert Haas writes:
> > If you have the timezone configured to a non-default value in
> > postgresql.conf, and you comment it out and reload, it says:
>
> > LOG: parameter "TimeZone" removed from configuration file, reset to default
>
> > ...but at least when I tested it, it d
On May 26, 2011, at 12:41 PM, Alvaro Herrera wrote:
> Yes, I think the lock-up is better than weird behavior. Maybe we should
> add a short note in a postgresql.conf comment to this effect, so that it
> doesn't surprise anyone that deletes or comments out the line.
+1 on both counts.
--
Jim C. Na
Excerpts from Robert Haas's message of dom may 22 23:09:47 -0400 2011:
> On Sun, May 22, 2011 at 10:24 PM, Tom Lane wrote:
> > Robert Haas writes:
> >> On Sun, May 22, 2011 at 9:54 PM, Tom Lane wrote:
> >>> But also, 99.999% of the time
> >>> it would be completely wasted effort because the DBA
On Sun, May 22, 2011 at 10:24 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sun, May 22, 2011 at 9:54 PM, Tom Lane wrote:
>>> But also, 99.999% of the time
>>> it would be completely wasted effort because the DBA wouldn't remove the
>>> postgresql.conf setting at all, ever.
>
>> Well, by that
Robert Haas writes:
> On Sun, May 22, 2011 at 9:54 PM, Tom Lane wrote:
>> But also, 99.999% of the time
>> it would be completely wasted effort because the DBA wouldn't remove the
>> postgresql.conf setting at all, ever.
> Well, by that argument, we ought not to worry about masterminding what
>
On Sun, May 22, 2011 at 9:54 PM, Tom Lane wrote:
>> If not, then how about jiggering things somehow so that only one
>> server process needs to run the hack? Perhaps it can drop the result
>> in a file or shared memory or something from which the remaining
>> backends can read it out without havi
Robert Haas writes:
> On Thu, May 19, 2011 at 12:19 PM, Tom Lane wrote:
>> What would make everybody happy is to find a way of identifying the
>> system timezone that isn't such a massive, expensive kluge. Any ideas?
> ...reads the code...
> Good grief. What an incredibly ugly hack. Is there s
On Thu, May 19, 2011 at 12:19 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, May 19, 2011 at 12:12 PM, Tom Lane wrote:
>>> 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 tim
Robert Haas writes:
> On Thu, May 19, 2011 at 12:12 PM, Tom Lane wrote:
>> 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
On Thu, May 19, 2011 at 12:12 PM, Tom Lane wrote:
> Robert Haas 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
>> immedi
Robert Haas 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 reve
On Thu, Apr 7, 2011 at 1:36 AM, Tom Lane wrote:
> Robert Haas writes:
>> If you have the timezone configured to a non-default value in
>> postgresql.conf, and you comment it out and reload, it says:
>
>> LOG: parameter "TimeZone" removed from configuration file, reset to default
>
>> ...but at l
Robert Haas writes:
> If you have the timezone configured to a non-default value in
> postgresql.conf, and you comment it out and reload, it says:
> LOG: parameter "TimeZone" removed from configuration file, reset to default
> ...but at least when I tested it, it didn't actually appear to reset
If you have the timezone configured to a non-default value in
postgresql.conf, and you comment it out and reload, it says:
LOG: parameter "TimeZone" removed from configuration file, reset to default
...but at least when I tested it, it didn't actually appear to reset
it to the default.
assign_t
23 matches
Mail list logo
