Re: [HACKERS] Cutting initdb's runtime (Perl question embedded)
От | Alvaro Herrera |
---|---|
Тема | Re: [HACKERS] Cutting initdb's runtime (Perl question embedded) |
Дата | |
Msg-id | 20180509153924.32kvslqeqdyco7c5@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: [HACKERS] Cutting initdb's runtime (Perl question embedded) (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] Cutting initdb's runtime (Perl question embedded)
Re: [HACKERS] Cutting initdb's runtime (Perl question embedded) |
Список | pgsql-hackers |
Tom Lane wrote: > Robert Haas <robertmhaas@gmail.com> writes: > > On Tue, May 8, 2018 at 4:48 PM, Tom Lane <tgl@sss.pgh.pa.us> 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 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 about that, but I'm afraid it's often a hardlink not a > symlink. Still, we could try it. 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 would use the slow fallback only for rare cases. (Maybe have initdb emit a warning when the fallback is used, so that we know what else to look for.) This comment is insightful: https://github.com/HowardHinnant/date/issues/269#issuecomment-353792132 It's talking about this code: https://github.com/HowardHinnant/date/blob/master/src/tz.cpp#L3652 -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: