8000 Work around portability issue with newer versions of mktime(). · postgres/postgres@05fccab · GitHub
[go: up one dir, main page]
Skip to content

Commit 05fccab

Browse files
tglsfdctglsfdc
committed
Work around portability issue with newer versions of mktime().
Recent glibc versions have made mktime() fail if tm_isdst is inconsistent with the prevailing timezone; in particular it fails for tm_isdst = 1 when the zone is UTC. (This seems wildly inconsistent with the POSIX-mandated treatment of "incorrect" values for the other fields of struct tm, so if you ask me it's a bug, but I bet they'll say it's intentional.) This has been observed to cause cosmetic problems when pg_restore'ing an archive created in a different timezone. To fix, do mktime() using the field values from the archive, and if that fails try again with tm_isdst = -1. This will give a result that's off by the UTC-offset difference from the original zone, but that was true before, too. It's not terribly critical since we don't do anything with the result except possibly print it. (Someday we should flush this entire bit of logic and record a standard-format timestamp in the archive instead. That's not okay for a back-patched bug fix, though.) Also, guard our only other use of mktime() by having initdb's build_time_t() set tm_isdst = -1 not 0. This case could only have an issue in zones that are DST year-round; but I think some do exist, or could in future. Per report from Wells Oliver. Back-patch to all supported versions, since any of them might need to run with a newer glibc. Discussion: https://postgr.es/m/CAOC+FBWDhDHO7G-i1_n_hjRzCnUeFO+H-Czi1y10mFhRWpBrew@mail.gmail.com
1 parent 319d616 commit 05fccab

File tree

2 files changed

+28
-5
lines changed

2 files changed

+28
-5
lines changed

‎src/bin/initdb/findtimezone.c

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -195,6 +195,7 @@ build_time_t(int year, int month, int day)
195195
tm.tm_mday = day;
196196
tm.tm_mon = month - 1;
197197
tm.tm_year = year - 1900;
198+
tm.tm_isdst = -1;
198199

199200
return mktime(&tm);
200201
}

‎src/bin/pg_dump/pg_backup_archiver.c

Lines changed: 27 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -3675,7 +3675,6 @@ ReadHead(ArchiveHandle *AH)
36753675
vmin,
36763676
vrev;
36773677
int fmt;
3678-
struct tm crtm;
36793678

36803679
/*
36813680
* If we haven't already read the header, do so.
@@ -3743,6 +3742,8 @@ ReadHead(ArchiveHandle *AH)
37433742

37443743
if (AH->version >= K_VERS_1_4)
37453744
{
3745+
struct tm crtm;
3746+
37463747
crtm.tm_sec = ReadInt(AH);
37473748
crtm.tm_min = ReadInt(AH);
37483749
crtm.tm_hour = ReadInt(AH);
@@ -3751,12 +3752,33 @@ ReadHead(ArchiveHandle *AH)
37513752
crtm.tm_year = ReadInt(AH);
37523753
crtm.tm_isdst = ReadInt(AH);
37533754

3754-
AH->archdbname = ReadStr(AH);
3755-
3755+
/*
3756+
* Newer versions of glibc have mktime() report failure if tm_isdst is
3757+
* inconsistent with the prevailing timezone, e.g. tm_isdst = 1 when
3758+
* TZ=UTC. This is problematic when restoring an archive under a
3759+
* different timezone setting. If we get a failure, try again with
3760+
* tm_isdst set to -1 ("don't know").
3761+
*
3762+
* XXX with or without this hack, we reconstruct createDate
3763+
* incorrectly when the prevailing timezone is different from
3764+
* pg_dump's. Next time we bump the archive version, we should flush
3765+
* this representation and store a plain seconds-since-the-Epoch
3766+
* timestamp instead.
3767+
*/
37563768
AH->createDate = mktime(&crtm);
3757-
37583769
if (AH->createDate == (time_t) -1)
3759-
write_msg(modulename, "WARNING: invalid creation date in header\n");
3770+
{
3771+
crtm.tm_isdst = -1;
3772+
AH->createDate = mktime(&crtm);
3773+
if (AH->createDate == (time_t) -1)
3774+
write_msg(modulename,
3775+
"WARNING: invalid creation date in header\n");
3776+
}
3777+
}
3778+
3779+
if (AH->version >= K_VERS_1_4)
3780+
{
3781+
AH->archdbname = ReadStr(AH);
37603782
}
37613783

37623784
if (AH->version >= K_VERS_1_10)

0 commit comments

Comments
 (0)
0