Andres Freund writes:
> Fair enough. I'm mildly worried that people will just carry their
> timezone setting from one version's postgresql.conf to the next as they
> upgrade.
Maybe. I don't believe pg_upgrade copies over the old postgresql.conf,
and I doubt we should consider it good practice
Hi,
On 2019-08-01 13:59:11 -0400, Tom Lane wrote:
> Andres Freund writes:
> > When used and a symlink, could we resolve the symlink when determining
> > the timezone? When loading a timezone in the backend, not during
> > initdb. While that'd leave us with the instability, it'd at least would
>
Andres Freund writes:
> When used and a symlink, could we resolve the symlink when determining
> the timezone? When loading a timezone in the backend, not during
> initdb. While that'd leave us with the instability, it'd at least would
> help clients etc understand what the setting actually
Hi,
On 2019-08-01 10:08:01 -0400, Tom Lane wrote:
> I have in fact committed that patch. It won't do anything for your
> problem with respect to existing installations that may have picked
> "localtime", but it'll at least prevent new initdb runs from picking
> that.
> Avoid choosing
Tom,
> I have in fact committed that patch. It won't do anything for your
> problem with respect to existing installations that may have picked
>"localtime", but it'll at least prevent new initdb runs from picking
> that.
Thanks! At least over time the problem will hopefully diminish.
Shay Rojansky writes:
>> I'm not sure we're any closer to a meeting of the minds on whether
>> consulting zone[1970].tab is a good thing to do, but we got an actual
>> user complaint[1] about how "localtime" should not be a preferred
>> spelling. So I want to go ahead and insert the discussed
> I'm not sure we're any closer to a meeting of the minds on whether
> consulting zone[1970].tab is a good thing to do, but we got an actual
> user complaint[1] about how "localtime" should not be a preferred
> spelling. So I want to go ahead and insert the discussed anti-preference
> against
Thomas Munro writes:
> FWIW this is now fixed for FreeBSD 13-CURRENT, with a good chance of
> back-patch. I don't know if there are any other operating systems
> that are shipping zoneinfo but failing to install zone1970.tab, but if
> there are it's a mistake IMHO and they'll probably fix that
On Thu, Jun 27, 2019 at 10:48 AM Andrew Gierth
wrote:
> > "Tom" == Tom Lane writes:
> Tom> No zone1970.tab.
>
> zone.tab is an adequate substitute - a fact which I thought was
> sufficiently obvious as to not be worth mentioning.
>
> (also see https://reviews.freebsd.org/D20646 )
FWIW this
> "Tom" == Tom Lane writes:
Tom> I'm dubious that relying on zone[1970].tab would improve matters
Tom> substantially; it would fix some cases, but I don't think it would
Tom> fix all of them. Resolving all ambiguous zone-name choices is not
Tom> the charter of those files.
Allowing zone
Robert Haas writes:
> Long story short, I agree with you that most people probably don't
> care about this very much, but I also agree with Andrew that some of
> the current choices we're making are pretty strange, and I'm not
> convinced as you are that it's impossible to make a principled
On Thu, Jun 27, 2019 at 1:58 PM Tom Lane wrote:
> It's not really clear to me that the IANA folk intend those files to
> be read as a list of preferred zone names. If they do, what are we
> to make of the fact that no variant of "UTC" appears in them?
I think their intent is key. We can't make
> "Tom" == Tom Lane writes:
> Robert Haas writes:
>> I'm kind of unsure what to think about this whole debate
>> substantively. If Andrew is correct that zone.tab or zone1970.tab is
>> a list of time zone names to be preferred over alternatives, then it
>> seems like we ought to prefer
Robert Haas writes:
> I'm kind of unsure what to think about this whole debate
> substantively. If Andrew is correct that zone.tab or zone1970.tab is a
> list of time zone names to be preferred over alternatives, then it
> seems like we ought to prefer them.
It's not really clear to me that the
On Tue, Jun 25, 2019 at 8:18 PM Tom Lane wrote:
> As long as we have a trivial and obviously apolitical rule like
> alphabetical order, I think we can skate over such things; but the minute
> we have any sort of human choices involved there, we're going to be
> getting politically driven requests
Andrew Gierth writes:
> "Tom" == Tom Lane writes:
> Tom> In general, the point I'm trying to make is that our policy should
> Tom> be "Ties are broken arbitrarily, and if you don't like the choice
> Tom> that initdb makes, here's how to fix it".
> Yes, you've repeated that point at some
Greetings,
* Daniel Gustafsson (dan...@yesql.se) wrote:
> > On 27 Jun 2019, at 00:48, Andrew Gierth wrote:
>
> > Tom> In general, the point I'm trying to make is that our policy should
> > Tom> be "Ties are broken arbitrarily, and if you don't like the choice
> > Tom> that initdb makes, here's
> On 27 Jun 2019, at 00:48, Andrew Gierth wrote:
> Tom> In general, the point I'm trying to make is that our policy should
> Tom> be "Ties are broken arbitrarily, and if you don't like the choice
> Tom> that initdb makes, here's how to fix it".
>
> Yes, you've repeated that point at some
> "Tom" == Tom Lane writes:
Tom> No zone1970.tab.
zone.tab is an adequate substitute - a fact which I thought was
sufficiently obvious as to not be worth mentioning.
(also see https://reviews.freebsd.org/D20646 )
Tom> I do not think we can rely on that file being there, since zic
Tom>
Further on this --- I now remember that the reason we used to want to
reject the "Factory" timezone is that it used to report this as the
zone abbreviation:
Local time zone must be set--see zic manual page
which (a) resulted in syntactically invalid timestamp output from the
timeofday()
Andrew Gierth writes:
> "Thomas" == Thomas Munro writes:
> Thomas> Right. On a FreeBSD system here in New Zealand you get "NZ"
> Thomas> with default configure options (ie using PostgreSQL's tzdata).
> Thomas> But if you build with --with-system-tzdata=/usr/share/zoneinfo
> Thomas> you get
> "Thomas" == Thomas Munro writes:
>> Pacific/Auckland -> NZ
Thomas> Right. On a FreeBSD system here in New Zealand you get "NZ"
Thomas> with default configure options (ie using PostgreSQL's tzdata).
Thomas> But if you build with --with-system-tzdata=/usr/share/zoneinfo
Thomas> you get
On Wed, Jun 26, 2019 at 6:32 PM Andrew Gierth
wrote:
> Pacific/Auckland -> NZ
Right. On a FreeBSD system here in New Zealand you get "NZ" with
default configure options (ie using PostgreSQL's tzdata). But if you
build with --with-system-tzdata=/usr/share/zoneinfo you get
"Pacific/Auckland",
> "Tom" == Tom Lane writes:
Tom> TBH, I find this borderline insane: it's taking a problem we did
Tom> not have and moving the goalposts to the next county. Not just any
Tom> old county, either, but one where there's a shooting war going on.
Tom> As soon as you do something like putting
Andrew Gierth writes:
> I was planning on submitting a follow-up myself (for pg13+) for
> discussion of further improvements. My suggestion would be that we
> should have the following order of preference, from highest to lowest:
> - UTC (justified by being an international standard)
> -
[ starting to come up for air again after a truly nasty sinus infection...
fortunately, once I stopped thinking it was "a cold" and went to the
doctor, antibiotics seem to be working ]
Andrew Gierth writes:
> "Tom" == Tom Lane writes:
> Tom> 1 Europe/Isle_of_Man
> Is this from HEAD
Andrew Gierth writes:
> Tom's "fix" of backpatching 23bd3cec6 (which happened on Friday 14th)
> addressed only a subset of cases, as far as I know working only on Linux
> (the historical convention has always been for /etc/localtime to be a
> copy of a zonefile, not a symlink to one). I only
Andrew Gierth writes:
> "Tom" == Tom Lane writes:
> Tom> Keep in mind that dealing with whatever tzdb chooses to ship is
> Tom> not optional from our standpoint. Even if we'd refused to import
> Tom> 2019a, every installation using --with-system-tzdata (which, I
> Tom> sincerely hope,
> "Tom" == Tom Lane writes:
>> I was referring to the fact that the regression was introduced by a,
>> presumably important, tzdb update (2019a, as mentioned above). At
>> least, I made the assumption that the commit of the import of 2019a
>> had more than just the change that introduced
Stephen Frost writes:
> * Andrew Gierth (and...@tao11.riddles.org.uk) wrote:
> "Stephen" == Stephen Frost writes:
>> Stephen> Piling on to that, the regression was entwined with other
>> Stephen> important changes that we wanted to include in the release.
>>
>> I'm not sure what you're
Greetings,
* Andrew Gierth (and...@tao11.riddles.org.uk) wrote:
> > "Stephen" == Stephen Frost writes:
>
> Stephen> In the situation that started this discussion, a change had
> Stephen> already been made and it was only later realized that it
> Stephen> caused a regression.
>
> Just to
> "Stephen" == Stephen Frost writes:
Stephen> In the situation that started this discussion, a change had
Stephen> already been made and it was only later realized that it
Stephen> caused a regression.
Just to keep the facts straight:
The regression was introduced by importing tzdb
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Jun 20, 2019 at 1:28 PM Alvaro Herrera
> wrote:
> > I suppose we could have a moratorium on commits starting from (say) EOB
> > Wednesday of the week prior to the release; patches can only be
> > committed after that if they have
On Thu, Jun 20, 2019 at 1:28 PM Alvaro Herrera wrote:
> I suppose we could have a moratorium on commits starting from (say) EOB
> Wednesday of the week prior to the release; patches can only be
> committed after that if they have ample support (where "ample support"
> might be defined as having
On 2019-Jun-20, Andres Freund wrote:
> On 2019-06-20 12:02:30 -0400, Robert Haas wrote:
> > I agree that it's a difficult situation. I do kind of wonder whether
> > we were altogether overreacting. If we had shipped it as it was,
> > what's the worst thing that would have happened?
>
> I
Greetings,
* Andres Freund (and...@anarazel.de) wrote:
> On 2019-06-20 12:02:30 -0400, Robert Haas wrote:
> > On Thu, Jun 20, 2019 at 8:52 AM Stephen Frost wrote:
> > > I don't want to come across as implying that I'm saying what was done
> > > was 'fine', or that we shouldn't be having this
Hi,
On 2019-06-20 12:02:30 -0400, Robert Haas wrote:
> On Thu, Jun 20, 2019 at 8:52 AM Stephen Frost wrote:
> > I don't want to come across as implying that I'm saying what was done
> > was 'fine', or that we shouldn't be having this conversation, I'm just
> > trying to figure out how we can
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Also on the topic of process: 48 hours before a wrap deadline is
> *particularly* not the time to play fast and loose with this sort of
> thing. It'd have been better to wait till after this week's releases,
> so there'd at least be time to
I wrote:
> So I'm toying with the idea of extending Andrew's patch to put a negative
> preference on "localtime", ensuring we'll use some other name for the zone
> if one is available.
Oh ... after further review it seems like "posixrules" should be
de-preferred on the same basis: it's
On Thu, Jun 20, 2019 at 10:48 AM Tom Lane wrote:
> As of now, six of the seven UCT-reporting members have switched to UTC;
> the lone holdout is elver which hasn't run in ten days. (Perhaps it
> zneeds unwedged.) There are no other changes, so it seems like Andrew's
> patch is doing what it
BTW ... now that that patch has been in long enough to collect some
actual data on what it's doing, I set out to scrape the buildfarm logs
to see what is happening in the farm. Here are the popularities of
various timezone settings, as of the end of May:
3 America/Los_Angeles
9
Robert Haas writes:
> On Mon, Jun 17, 2019 at 2:41 PM Stephen Frost wrote:
>> Ah, ok, I agree that would have been good to do. Of course, hindsight
>> being 20/20 and all that. Something to keep in mind for the future
>> though.
> I think it was inappropriate to commit this at all. You can't
On Mon, Jun 17, 2019 at 2:41 PM Stephen Frost wrote:
> Ah, ok, I agree that would have been good to do. Of course, hindsight
> being 20/20 and all that. Something to keep in mind for the future
> though.
I think it was inappropriate to commit this at all. You can't just
say "some other
Greetings,
* Andres Freund (and...@anarazel.de) wrote:
> On 2019-06-17 14:34:58 -0400, Stephen Frost wrote:
> > * Andres Freund (and...@anarazel.de) wrote:
> > > On 2019-06-14 23:14:09 +0100, Andrew Gierth wrote:
> > > > So here is my current proposed fix.
> > >
> > > Before pushing a commit
Hi,
On 2019-06-17 14:34:58 -0400, Stephen Frost wrote:
> * Andres Freund (and...@anarazel.de) wrote:
> > On 2019-06-14 23:14:09 +0100, Andrew Gierth wrote:
> > > So here is my current proposed fix.
> >
> > Before pushing a commit that's controversial - and this clearly seems to
> > somewhat be -
Greetings,
* Andres Freund (and...@anarazel.de) wrote:
> On 2019-06-14 23:14:09 +0100, Andrew Gierth wrote:
> > So here is my current proposed fix.
>
> Before pushing a commit that's controversial - and this clearly seems to
> somewhat be - it'd be good to give others a heads up that you intend
On 2019-06-14 23:14:09 +0100, Andrew Gierth wrote:
> So here is my current proposed fix.
Before pushing a commit that's controversial - and this clearly seems to
somewhat be - it'd be good to give others a heads up that you intend to
do so, so they can object. Rather than just pushing less than
Re: Tom Lane 2019-06-14 <26948.1560517...@sss.pgh.pa.us>
> > /usr/lib/postgresql/12/bin/initdb -D pgdata
> > $ grep timezone pgdata/postgresql.conf
> > log_timezone = 'Etc/UTC'
> > timezone = 'Etc/UTC'
>
> That's what I'd expect. Do you think your upthread report of HEAD
> picking "Etc/UCT" was
> "Andrew" == Andrew Gierth writes:
> "Tom" == Tom Lane writes:
>>> This isn't good enough, because it still picks "UCT" on a system
>>> with no /etc/localtime and no TZ variable. Testing on HEAD as of
>>> 3da73d683 (on FreeBSD, but it'll be the same anywhere else):
Tom> [ shrug...
> "Tom" == Tom Lane writes:
>> This isn't good enough, because it still picks "UCT" on a system
>> with no /etc/localtime and no TZ variable. Testing on HEAD as of
>> 3da73d683 (on FreeBSD, but it'll be the same anywhere else):
Tom> [ shrug... ] Too bad. I doubt that that's a common
On Fri, Jun 14, 2019, 3:12 PM Tom Lane wrote:
> A possibly better idea is to push back on tzdb's choice to unify
> these zones. Don't know if they'd listen, but we could try. The
> UCT symlink hasn't been out there so long that it's got much inertia.
One oddity; AIX had a preference for CUT
> "Tom" == Tom Lane writes:
>> This isn't good enough, because it still picks "UCT" on a system with no
>> /etc/localtime and no TZ variable. Testing on HEAD as of 3da73d683 (on
>> FreeBSD, but it'll be the same anywhere else):
Tom> [ shrug... ] Too bad. I doubt that that's a common
Andrew Gierth writes:
> This isn't good enough, because it still picks "UCT" on a system with no
> /etc/localtime and no TZ variable. Testing on HEAD as of 3da73d683 (on
> FreeBSD, but it'll be the same anywhere else):
[ shrug... ] Too bad. I doubt that that's a common situation anyway.
> We
> "Tom" == Tom Lane writes:
>>> Anyway, moving on to the question of what should we do about this,
>>> I don't really have anything better to offer than back-patching
>>> 23bd3cec6.
>> The PG12 behavior seems sane, so +1.
Tom> OK, I'll make that happen.
This isn't good enough,
Christoph Berg writes:
> Re: Tom Lane 2019-06-11 <24452.1560285...@sss.pgh.pa.us>
>> The only way I can get it to pick "Etc/UCT" is if that's what I put
>> into /etc/localtime. (In which case I maintain that that's not a bug,
>> or at least not our bug.)
> Did you try a symlink or a plain file
Re: Tom Lane 2019-06-11 <24452.1560285...@sss.pgh.pa.us>
> The only way I can get it to pick "Etc/UCT" is if that's what I put
> into /etc/localtime. (In which case I maintain that that's not a bug,
> or at least not our bug.)
Did you try a symlink or a plain file for /etc/localtime?
> So I'm
Christoph Berg writes:
> In the meantime I realized that I was only testing /etc/timezone
> (which is a plain file with just the zone name), while not touching
> /etc/localtime at all. In this environment, it's a symlink:
> lrwxrwxrwx 1 root root 27 Mär 28 14:49 /etc/localtime ->
>
Andres Freund writes:
> On 2019-06-06 12:51:30 -0400, Tom Lane wrote:
>> Sure, that is intentionally a behavior change in this situation.
>> The theory is that if "Etc/UCT" is what the user put in /etc/localtime,
>> then that's the spelling she wants. See 23bd3cec6.
> Right, I'm not complaining
Hi,
On 2019-06-06 12:51:30 -0400, Tom Lane wrote:
> [ sorry for slow response, I'm on vacation ]
Good.
> Andres Freund writes:
> > That makes sense. As far as I can tell the reason that 12 sometimes ends
> > up with the proper timezone is that we shortcut the search by:
>
> > /*
> >
[ sorry for slow response, I'm on vacation ]
Andres Freund writes:
> That makes sense. As far as I can tell the reason that 12 sometimes ends
> up with the proper timezone is that we shortcut the search by:
> /*
>* Try to avoid the brute-force search by seeing if we can recognize
Re: Tom Lane 2019-06-04 <65800.1559662...@sss.pgh.pa.us>
> > There is something wrong here. On Debian Buster/unstable, using
> > system tzdata (2019a-1), if /etc/timezone is "Etc/UTC":
>
> Is your build using --with-system-tzdata? If so, which tzdb
> release is the system on, and is it a
Hi,
On 2019-06-04 17:20:42 +0100, Andrew Gierth wrote:
> fwiw on FreeBSD with no /etc/localtime and no TZ in the environment (and
> hence running on UTC), I get "UCT" on both 11.3 and HEAD.
That makes sense. As far as I can tell the reason that 12 sometimes ends
up with the proper timezone is
Hi,
On 2019-06-04 08:53:30 -0700, Andres Freund wrote:
> If I set the system-wide default, using dpkg-reconfigure -plow tzdata,
> to UTC I *do* get Etc/UTC.
>
> root@alap4:/home/andres/src/postgresql# cat /etc/timezone
> Etc/UTC
> root@alap4:/home/andres/src/postgresql# ls -l /etc/timezone
>
> "Christoph" == Christoph Berg writes:
Christoph> There is something wrong here. On Debian Buster/unstable,
Christoph> using system tzdata (2019a-1), if /etc/timezone is
Christoph> "Etc/UTC":
Christoph> 11.3's initdb adds timezone = 'UCT' to postgresql.conf
Christoph> 12beta1's initdb
Hi,
On 2019-06-04 11:27:31 -0400, Tom Lane wrote:
> $ TZ=UTC initdb
> ...
> selecting default timezone ... UTC
> ...
Btw, if the input is Etc/UTZ, do you also get UTC or Etc/UTZ? Because it
seems that debian only configures Etc/UTZ on a system-wide basis
now. Which seems not insane, given that's
> "Tom" == Tom Lane writes:
> Andrew Gierth writes:
>> I believe I pointed out a long, long time ago that this tie-breaking
>> strategy was insane, and that the rule should be to prefer canonical
>> names and use something else only in the case of a strictly better
>> match.
Tom>
Hi,
On 2019-06-04 11:27:31 -0400, Tom Lane wrote:
> Hm, I don't have a Debian machine at hand, but I'm unable to
> reproduce this using macOS or RHEL. I tried things like
>
> $ TZ=UTC initdb
> ...
> selecting default timezone ... UTC
> ...
On debian unstable that's what I get too, both with
Andrew Gierth writes:
> I believe I pointed out a long, long time ago that this tie-breaking
> strategy was insane, and that the rule should be to prefer canonical
> names and use something else only in the case of a strictly better
> match.
This is assuming that the tzdb data has a concept of a
Christoph Berg writes:
> There is something wrong here. On Debian Buster/unstable, using
> system tzdata (2019a-1), if /etc/timezone is "Etc/UTC":
> 11.3's initdb adds timezone = 'UCT' to postgresql.conf
> 12beta1's initdb add timezone = 'Etc/UCT' to postgresql.conf
Hm, I don't have a Debian
> "Christoph" == Christoph Berg writes:
>> Etc/UCT is now a backward-compatibility link to Etc/UTC, instead of
>> being a separate zone that generates the abbreviation "UCT", which
>> nowadays is typically a typo. Postgres will still accept "UCT" as an
>> input zone name, but it won't
70 matches
Mail list logo
