Peter Eisentraut <pete...@gmx.net> writes: > Fix bool/int type confusion > Using ++ on a bool variable doesn't work well when stdbool.h is in use. > The original BSD code appears to use int here, so use that instead.
I'm fairly unhappy with this approach to fixing this problem, because localtime.c is not Postgres-maintained code; we try to keep it in sync with the upstream copy maintained by the IANA timezone crew. Patching it like this will interfere with the next sync attempt, and patching it only in master will cause back-patching of that sync patch to fail. I checked the tz list archives and discovered that this problem was already reported to them back in May: http://mm.icann.org/pipermail/tz/2017-May/024995.html Although indeed their previous coding had had the variable as "int", their response was not to change it back to int, but to get rid of the loop incrementing it, because that was intended to support the possibility of 2 leap seconds on the same day, which according to them is a widespread misunderstanding of the applicable standard. So the code in their git repo still has the variable as bool, but there's no ++ operator on it anymore. This also means that the portability problem is purely hypothetical; given valid tz reference data the code wouldn't ever try to increment "hit" to 2 anyway. It's even more hypothetical for us, because we don't use leap-second-aware zones. They've not made a new tzcode release since May, due to lack of political activity in this sphere this year, although I gather that one is likely by November or so. However, we have precedent for sometimes syncing with their git tip to absorb code bug fixes, cf commit 7afafe8af. Therefore, what I would like to do is revert this commit (0ec2e908b), and then either leave the problem to be fixed by our next regular sync with a released tzcode version, or else force a sync with their git tip to absorb their fix now. In either case we should keep all our live branches in sync. I'm willing to do the code-sync work either way. Comments? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers