On ons, 2011-09-07 at 17:16 -0400, Tom Lane wrote:
Magnus Hagander mag...@hagander.net writes:
On Tue, Sep 6, 2011 at 23:52, Robert Haas robertmh...@gmail.com wrote:
On Tue, Sep 6, 2011 at 5:16 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Although there's always more than one way to skin a cat.
Peter Eisentraut pete...@gmx.net 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
On Tue, Sep 6, 2011 at 23:52, Robert Haas robertmh...@gmail.com wrote:
On Tue, Sep 6, 2011 at 5:16 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I wrote:
Robert Haas robertmh...@gmail.com writes:
I am (and, I think, Alvaro is also) of the opinion that the behavior
here is still not really right.
I
Magnus Hagander mag...@hagander.net writes:
On Tue, Sep 6, 2011 at 23:52, Robert Haas robertmh...@gmail.com wrote:
On Tue, Sep 6, 2011 at 5:16 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Although there's always more than one way to skin a cat. Consider
this idea:
1. The hard-wired default for
Tom Lane wrote:
Robert Haas robertmh...@gmail.com 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
Bruce Momjian br...@momjian.us 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
On Tue, Sep 6, 2011 at 3:31 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Bruce Momjian br...@momjian.us 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
Robert Haas robertmh...@gmail.com writes:
On Tue, Sep 6, 2011 at 3:31 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Bruce Momjian br...@momjian.us writes:
Was this dealt with?
Yes, as much as I think is reasonable anyway. See
commit e05b866447899211a0c2df31bf0671faac4fc3e5.
I am (and, I think,
I wrote:
Robert Haas robertmh...@gmail.com 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().
On Tue, Sep 6, 2011 at 5:16 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I wrote:
Robert Haas robertmh...@gmail.com 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
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.
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 t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Sun, May 22, 2011 at 9:54 PM, Tom Lane t...@sss.pgh.pa.us wrote:
But also, 99.999% of the time
it would
On Thu, May 19, 2011 at 12:19 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, May 19, 2011 at 12:12 PM, Tom Lane t...@sss.pgh.pa.us wrote:
We could do that, but the issue that this code is trying to avoid is
that identify_system_timezone can easily add
Robert Haas robertmh...@gmail.com writes:
On Thu, May 19, 2011 at 12:19 PM, Tom Lane t...@sss.pgh.pa.us 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
On Sun, May 22, 2011 at 9:54 PM, Tom Lane t...@sss.pgh.pa.us 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
Robert Haas robertmh...@gmail.com writes:
On Sun, May 22, 2011 at 9:54 PM, Tom Lane t...@sss.pgh.pa.us 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
On Sun, May 22, 2011 at 10:24 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Sun, May 22, 2011 at 9:54 PM, Tom Lane t...@sss.pgh.pa.us wrote:
But also, 99.999% of the time
it would be completely wasted effort because the DBA wouldn't remove the
On Thu, Apr 7, 2011 at 1:36 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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,
Robert Haas robertmh...@gmail.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
On Thu, May 19, 2011 at 12:12 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.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
Robert Haas robertmh...@gmail.com writes:
On Thu, May 19, 2011 at 12:12 PM, Tom Lane t...@sss.pgh.pa.us 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
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.
Robert Haas robertmh...@gmail.com 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
23 matches
Mail list logo
