Thomas Munro writes:
> I noticed that the patch does a bunch of s/Olson/IANA/. That leaves
> only one place in the tree that still refers to the "Olson" database:
> dt_common.c. Might want to change that too?
Ah, I didn't realize we were that close to wiping out the old
terminology. Yeah, I'll
On Wed, Sep 12, 2018 at 08:04:53PM -0300, Alvaro Herrera wrote:
> Well, mine is there, and it's correct:
>
> Li America/Santiago Chile/Continental
> Li Pacific/Easter Chile/EasterIsland
>
> Laugh all you want about Chile of all countries having multiple
> timezones ...
Impressed is a better word
On Thu, Sep 13, 2018 at 11:20 AM Tom Lane wrote:
> Michael Paquier writes:
> > On Wed, Sep 12, 2018 at 10:00:21AM -0400, Tom Lane wrote:
> >> I believe that this patch will never make for any functional change,
> >> it will only give you some other alias for the zone it would have
> >> selected a
Michael Paquier writes:
> On Wed, Sep 12, 2018 at 10:00:21AM -0400, Tom Lane wrote:
>> I believe that this patch will never make for any functional change,
>> it will only give you some other alias for the zone it would have
>> selected anyway.
> Looking at the list of aliases, I am not seeing li
On 2018-Sep-13, Michael Paquier wrote:
> Looking at the list of aliases, I am not seeing listed countries running
> across multiple timezones, so that may be fine..
Well, mine is there, and it's correct:
Li America/Santiago Chile/Continental
Li Pacific/Easter Chile/EasterIsland
Laugh all you wa
On Wed, Sep 12, 2018 at 10:00:21AM -0400, Tom Lane wrote:
> Michael Paquier writes:
>> One thing that I can see changing with this patch is how timezone is set
>> in postgresql.conf. For example, on HEAD I get 'Japan' while this patch
>> gives back 'Asia/Tokyo'. Could it be an issue for countrie
Michael Paquier writes:
> One thing that I can see changing with this patch is how timezone is set
> in postgresql.conf. For example, on HEAD I get 'Japan' while this patch
> gives back 'Asia/Tokyo'. Could it be an issue for countries with
> multiple timezones? I am not sure how Russian systems
On Fri, Aug 10, 2018 at 02:31:25PM -0400, Tom Lane wrote:
> The cfbot points out that this has suffered bit-rot, so here's a rebased
> version --- no substantive changes.
+ /*
+* Try to read the symlink. If not there, not a symlink, etc etc, just
+* quietly fail; the precise reason need
I wrote:
>> ... I'll
>> take a look at whipping up something that checks /etc/localtime.
> Here's a draft patch. It seems to do what I expect on a couple of
> different macOS releases as well as recent Fedora.
The cfbot points out that this has suffered bit-rot, so here's a rebased
version --- n
"Jonathan S. Katz" writes:
>> On May 10, 2018, at 12:37 PM, Tom Lane wrote:
>> OTOH, in view of Josh's old gripe, maybe it could be argued to be a bug
>> fix, at least on platforms where it does anything.
> Read back to get some history/context on this, and from my vantage
> point it sounds like
> On May 10, 2018, at 12:37 PM, Tom Lane wrote:
>
> Andres Freund writes:
>> On 2018-05-10 12:18:19 -0400, Tom Lane wrote:
>>> Next question is what to do with this. Do we want to sit on it till
>>> v12, or sneak it in now?
>
>> Is there a decent argument for sneaking it in? I don't really ha
Robert Haas writes:
> On Thu, May 10, 2018 at 3:37 PM, Tom Lane wrote:
>> Yeah, I had hoped that this might make a noticeable difference on slower
>> buildfarm animals, but some testing shows that it's more likely to be
>> barely above the noise floor.
> Any idea why?
Well, maybe the noise floo
On Thu, May 10, 2018 at 3:37 PM, Tom Lane wrote:
> Yeah, I had hoped that this might make a noticeable difference on slower
> buildfarm animals, but some testing shows that it's more likely to be
> barely above the noise floor.
Any idea why?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.
Andres Freund writes:
> On 2018-05-10 12:18:19 -0400, Tom Lane wrote:
>> Next question is what to do with this. Do we want to sit on it till
>> v12, or sneak it in now?
> Is there a decent argument for sneaking it in? I don't really have an
> opinion. I don't think it'd really be arguable that t
Hi,
On 2018-05-10 12:18:19 -0400, Tom Lane wrote:
> Next question is what to do with this. Do we want to sit on it till
> v12, or sneak it in now?
Is there a decent argument for sneaking it in? I don't really have an
opinion. I don't think it'd really be arguable that this'll make testing
meanin
I wrote:
> ... I'll
> take a look at whipping up something that checks /etc/localtime.
Here's a draft patch. It seems to do what I expect on a couple of
different macOS releases as well as recent Fedora. Googling finds
some suggestions that there might be other locations for the symlink,
for ins
Alvaro Herrera writes:
> Tom Lane wrote:
>> Robert Haas writes:
>>> Who says we need a portable way? If we had something that worked on
>>> Linux and macOS, it would cover most developer environments. I wonder
>>> if readlink("/etc/localtime", buf, sz) might be a viable approach.
>> I wondered
On Wed, May 9, 2018 at 11:39 AM, Alvaro Herrera
wrote:
> In Debian systems, it's a symlink. Apparently in RHEL6 and older it's a
> copy or hardlink, and the file /etc/sysconfig/clock contains a ZONE
> variable that points to the right zone. Maybe if we add enough
> platform-dependent hacks, we w
Tom Lane wrote:
> Robert Haas writes:
> > On Tue, May 8, 2018 at 4:48 PM, Tom Lane wrote:
> >> Really the only thing here that jumps out as being unduly expensive for
> >> what it's doing is select_default_timezone. That is, and always has been,
> >> a brute-force algorithm; I wonder if there's
Robert Haas writes:
> On Tue, May 8, 2018 at 4:48 PM, Tom Lane wrote:
>> Really the only thing here that jumps out as being unduly expensive for
>> what it's doing is select_default_timezone. That is, and always has been,
>> a brute-force algorithm; I wonder if there's a way to do better?
> Who
On Tue, May 8, 2018 at 4:48 PM, Tom Lane wrote:
> Really the only thing here that jumps out as being unduly expensive for
> what it's doing is select_default_timezone. That is, and always has been,
> a brute-force algorithm; I wonder if there's a way to do better? We can
> probably guess that ev
Resurrecting this old thread ...
I decided it'd be interesting to re-examine where initdb's runtime
is going, seeing that we just got done with a lot of bootstrap data
restructuring. I stuck some timing code into initdb, and got
results like this:
creating directory /home/postgres/testversion/da
22 matches
Mail list logo
