Thomas Munro <thomas.munro@gmail.com> writes:
> FreeBSD users already have the choice between zoneinfo from base or
> the misc/zoneinfo port if for some reason they want to control tzdata
> updates separately. PostgreSQL and FreeBSD both track tzdata closely,
> and both pushed a commit for version 2019c into their stable branches
> within a couple of weeks of it being released, so I don't foresee any
> problem with this change, and staying in sync with libc seems to
> outweigh any other concerns IMHO.
Note that the normal situation, on a platform with a well-maintained
tzdata package, is that tzdata acquired via Postgres is going to lag
behind. That's because we don't ship tzdata updates until our next
quarterly release, while the OS vendor probably has a much more
streamlined process for package updates.
In the case of 2019c, I pushed it into our code while it was still
pretty fresh, because it was just a few days to 12rc1 and I thought
the RC should contain the latest tzdata. But usually we only bother
to sync from tzdata upstream when a quarterly release is impending.
In theory, it's possible that a tzdata update could break Postgres.
But it'd probably break a lot of other code too. In practice, the
IANA people are well aware of that hazard, so there is a *long*
delay between when they introduce a new tzcode feature and when
they're willing to start relying on it in tzdata. We try to stay
fairly current on our copy of tzcode, so that should only be a live
hazard for out-of-support Postgres branches.
(I was reminded of this just the other day when I had occasion
to run the 9.2 regression tests, and they failed because of a
no-longer-valid assumption about Venezuelan time. I should
rebuild that legacy installation without --with-system-tzdata,
I guess, so that it uses tzdata it's expecting.)
regards, tom lane