pgsql: Attempt to identify system timezone by reading /etc/localtimesy

Поиск
Список
Период
Сортировка
От Tom Lane
Тема pgsql: Attempt to identify system timezone by reading /etc/localtimesy
Дата
Msg-id E1hbo56-0003Aq-UR@gemulon.postgresql.org
обсуждение исходный текст
Список pgsql-committers
Attempt to identify system timezone by reading /etc/localtime symlink.

On many modern platforms, /etc/localtime is a symlink to a file within the
IANA database.  Reading the symlink lets us find out the name of the system
timezone directly, without going through the brute-force search embodied in
scan_available_timezones().  This shortens the runtime of initdb by some
tens of ms, which is helpful for the buildfarm, and it also allows us to
reliably select the same zone name the system was actually configured for,
rather than possibly choosing one of IANA's many zone aliases.  (For
example, in a system configured for "Asia/Tokyo", the brute-force search
would not choose that name but its alias "Japan", on the grounds of the
latter string being shorter.  More surprisingly, "Navajo" is preferred
to either "America/Denver" or "US/Mountain", as seen in an old complaint
from Josh Berkus.)

If /etc/localtime doesn't exist, or isn't a symlink, or we can't make
sense of its contents, or the contents match a zone we know but that
zone doesn't match the observed behavior of localtime(), fall back to
the brute-force search.

Also, tweak initdb so that it prints the zone name it selected.

In passing, replace the last few references to the "Olson" database in
code comments with "IANA", as that's been our preferred term since
commit b2cbced9e.

Back-patch of commit 23bd3cec6.  The original intention was to not
back-patch, since this can result in cosmetic behavioral changes ---
for example, on my own workstation initdb now chooses "America/New_York",
where it used to prefer "US/Eastern" which is equivalent and shorter.
However, our hand has been more or less forced by tzdb update 2019a,
which made the "UCT" zone fully equivalent to "UTC".  Our old code
now prefers "UCT" on the grounds of it being alphabetically first,
and that's making nobody happy.  Choosing the alias indicated by
/etc/localtime is a more defensible behavior.  (Users who don't like
the results can always force the decision by setting the TZ environment
variable before running initdb.)

Patch by me, per a suggestion from Robert Haas; review by Michael Paquier

Discussion: https://postgr.es/m/7408.1525812528@sss.pgh.pa.us
Discussion: https://postgr.es/m/20190604085735.GD24018@msg.df7cb.de

Branch
------
REL_10_STABLE

Details
-------
https://git.postgresql.org/pg/commitdiff/8de574aa8bf7130f8291fc0be97e19a8074d2e05

Modified Files
--------------
src/bin/initdb/findtimezone.c              | 136 ++++++++++++++++++++++++++---
src/bin/initdb/initdb.c                    |   8 +-
src/interfaces/ecpg/pgtypeslib/dt_common.c |   2 +-
3 files changed, 133 insertions(+), 13 deletions(-)


В списке pgsql-committers по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: pgsql: Avoid spurious deadlocks when upgrading a tuple lock
Следующее
От: Tom Lane
Дата:
Сообщение: Re: pgsql: Avoid spurious deadlocks when upgrading a tuple lock