2004-04-30 06:09:23 +02:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
*
|
|
|
|
* pgtz.c
|
2004-05-01 03:34:47 +02:00
|
|
|
* Timezone Library Integration Functions
|
2004-04-30 06:09:23 +02:00
|
|
|
*
|
2020-01-01 18:21:45 +01:00
|
|
|
* Portions Copyright (c) 1996-2020, PostgreSQL Global Development Group
|
2004-04-30 06:09:23 +02:00
|
|
|
*
|
|
|
|
* IDENTIFICATION
|
2010-09-20 22:08:53 +02:00
|
|
|
* src/timezone/pgtz.c
|
2004-04-30 06:09:23 +02:00
|
|
|
*
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
*/
|
2004-05-21 07:08:06 +02:00
|
|
|
#include "postgres.h"
|
|
|
|
|
|
|
|
#include <ctype.h>
|
2006-10-16 21:58:27 +02:00
|
|
|
#include <fcntl.h>
|
2004-05-25 20:08:59 +02:00
|
|
|
#include <sys/stat.h>
|
2004-06-03 04:08:07 +02:00
|
|
|
#include <time.h>
|
2004-05-21 07:08:06 +02:00
|
|
|
|
2017-04-30 21:13:51 +02:00
|
|
|
#include "datatype/timestamp.h"
|
2004-05-21 07:08:06 +02:00
|
|
|
#include "miscadmin.h"
|
2004-04-30 06:09:23 +02:00
|
|
|
#include "pgtz.h"
|
2004-05-25 20:08:59 +02:00
|
|
|
#include "storage/fd.h"
|
2005-04-19 05:13:59 +02:00
|
|
|
#include "utils/hsearch.h"
|
|
|
|
|
2011-09-09 23:59:11 +02:00
|
|
|
|
2007-08-04 03:26:54 +02:00
|
|
|
/* Current session timezone (controlled by TimeZone GUC) */
|
|
|
|
pg_tz *session_timezone = NULL;
|
|
|
|
|
|
|
|
/* Current log timezone (controlled by log_timezone GUC) */
|
|
|
|
pg_tz *log_timezone = NULL;
|
2004-04-30 06:09:23 +02:00
|
|
|
|
|
|
|
|
2006-10-16 21:58:27 +02:00
|
|
|
static bool scan_directory_ci(const char *dirname,
|
2019-05-22 19:04:48 +02:00
|
|
|
const char *fname, int fnamelen,
|
|
|
|
char *canonname, int canonnamelen);
|
2004-05-25 20:08:59 +02:00
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Return full pathname of timezone data directory
|
|
|
|
*/
|
2007-08-25 22:29:25 +02:00
|
|
|
static const char *
|
2004-05-01 03:34:47 +02:00
|
|
|
pg_TZDIR(void)
|
|
|
|
{
|
2007-08-25 22:29:25 +02:00
|
|
|
#ifndef SYSTEMTZDIR
|
|
|
|
/* normal case: timezone stuff is under our share dir */
|
|
|
|
static bool done_tzdir = false;
|
|
|
|
static char tzdir[MAXPGPATH];
|
|
|
|
|
2004-04-30 06:09:23 +02:00
|
|
|
if (done_tzdir)
|
|
|
|
return tzdir;
|
|
|
|
|
2004-05-18 05:36:45 +02:00
|
|
|
get_share_path(my_exec_path, tzdir);
|
2006-10-16 21:58:27 +02:00
|
|
|
strlcpy(tzdir + strlen(tzdir), "/timezone", MAXPGPATH - strlen(tzdir));
|
2004-04-30 06:09:23 +02:00
|
|
|
|
2006-10-16 21:58:27 +02:00
|
|
|
done_tzdir = true;
|
2004-04-30 06:09:23 +02:00
|
|
|
return tzdir;
|
2007-08-25 22:29:25 +02:00
|
|
|
#else
|
|
|
|
/* we're configured to use system's timezone database */
|
|
|
|
return SYSTEMTZDIR;
|
|
|
|
#endif
|
2004-04-30 06:09:23 +02:00
|
|
|
}
|
2004-05-21 07:08:06 +02:00
|
|
|
|
2004-07-31 21:12:15 +02:00
|
|
|
|
2006-10-16 21:58:27 +02:00
|
|
|
/*
|
|
|
|
* Given a timezone name, open() the timezone data file. Return the
|
|
|
|
* file descriptor if successful, -1 if not.
|
|
|
|
*
|
|
|
|
* The input name is searched for case-insensitively (we assume that the
|
|
|
|
* timezone database does not contain case-equivalent names).
|
|
|
|
*
|
|
|
|
* If "canonname" is not NULL, then on success the canonical spelling of the
|
2011-09-09 23:59:11 +02:00
|
|
|
* given name is stored there (the buffer must be > TZ_STRLEN_MAX bytes!).
|
2006-10-16 21:58:27 +02:00
|
|
|
*/
|
|
|
|
int
|
|
|
|
pg_open_tzfile(const char *name, char *canonname)
|
|
|
|
{
|
|
|
|
const char *fname;
|
|
|
|
char fullname[MAXPGPATH];
|
|
|
|
int fullnamelen;
|
|
|
|
int orignamelen;
|
|
|
|
|
Improve performance of timezone loading, especially pg_timezone_names view.
tzparse() would attempt to load the "posixrules" timezone database file on
each call. That might seem like it would only be an issue when selecting a
POSIX-style zone name rather than a zone defined in the timezone database,
but it turns out that each zone definition file contains a POSIX-style zone
string and tzload() will call tzparse() to parse that. Thus, when scanning
the whole timezone file tree as we do in the pg_timezone_names view,
"posixrules" was read repetitively for each zone definition file. Fix
that by caching the file on first use within any given process. (We cache
other zone definitions for the life of the process, so there seems little
reason not to cache this one as well.) This probably won't help much in
processes that never run pg_timezone_names, but even one additional SET
of the timezone GUC would come out ahead.
An even worse problem for pg_timezone_names is that pg_open_tzfile()
has an inefficient way of identifying the canonical case of a zone name:
it basically re-descends the directory tree to the zone file. That's not
awful for an individual "SET timezone" operation, but it's pretty horrid
when we're inspecting every zone in the database. And it's pointless too
because we already know the canonical spelling, having just read it from
the filesystem. Fix by teaching pg_open_tzfile() to avoid the directory
search if it's not asked for the canonical name, and backfilling the
proper result in pg_tzenumerate_next().
In combination these changes seem to make the pg_timezone_names view
about 3x faster to read, for me. Since a scan of pg_timezone_names
has up to now been one of the slowest queries in the regression tests,
this should help some little bit for buildfarm cycle times.
Back-patch to all supported branches, not so much because it's likely
that users will care much about the view's performance as because
tracking changes in the upstream IANA timezone code is really painful
if we don't keep all the branches in sync.
Discussion: https://postgr.es/m/27962.1493671706@sss.pgh.pa.us
2017-05-03 03:50:35 +02:00
|
|
|
/* Initialize fullname with base name of tzdata directory */
|
|
|
|
strlcpy(fullname, pg_TZDIR(), sizeof(fullname));
|
|
|
|
orignamelen = fullnamelen = strlen(fullname);
|
|
|
|
|
|
|
|
if (fullnamelen + 1 + strlen(name) >= MAXPGPATH)
|
|
|
|
return -1; /* not gonna fit */
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If the caller doesn't need the canonical spelling, first just try to
|
|
|
|
* open the name as-is. This can be expected to succeed if the given name
|
|
|
|
* is already case-correct, or if the filesystem is case-insensitive; and
|
|
|
|
* we don't need to distinguish those situations if we aren't tasked with
|
|
|
|
* reporting the canonical spelling.
|
|
|
|
*/
|
|
|
|
if (canonname == NULL)
|
|
|
|
{
|
|
|
|
int result;
|
|
|
|
|
|
|
|
fullname[fullnamelen] = '/';
|
|
|
|
/* test above ensured this will fit: */
|
|
|
|
strcpy(fullname + fullnamelen + 1, name);
|
|
|
|
result = open(fullname, O_RDONLY | PG_BINARY, 0);
|
|
|
|
if (result >= 0)
|
|
|
|
return result;
|
|
|
|
/* If that didn't work, fall through to do it the hard way */
|
2017-05-07 17:34:31 +02:00
|
|
|
fullname[fullnamelen] = '\0';
|
Improve performance of timezone loading, especially pg_timezone_names view.
tzparse() would attempt to load the "posixrules" timezone database file on
each call. That might seem like it would only be an issue when selecting a
POSIX-style zone name rather than a zone defined in the timezone database,
but it turns out that each zone definition file contains a POSIX-style zone
string and tzload() will call tzparse() to parse that. Thus, when scanning
the whole timezone file tree as we do in the pg_timezone_names view,
"posixrules" was read repetitively for each zone definition file. Fix
that by caching the file on first use within any given process. (We cache
other zone definitions for the life of the process, so there seems little
reason not to cache this one as well.) This probably won't help much in
processes that never run pg_timezone_names, but even one additional SET
of the timezone GUC would come out ahead.
An even worse problem for pg_timezone_names is that pg_open_tzfile()
has an inefficient way of identifying the canonical case of a zone name:
it basically re-descends the directory tree to the zone file. That's not
awful for an individual "SET timezone" operation, but it's pretty horrid
when we're inspecting every zone in the database. And it's pointless too
because we already know the canonical spelling, having just read it from
the filesystem. Fix by teaching pg_open_tzfile() to avoid the directory
search if it's not asked for the canonical name, and backfilling the
proper result in pg_tzenumerate_next().
In combination these changes seem to make the pg_timezone_names view
about 3x faster to read, for me. Since a scan of pg_timezone_names
has up to now been one of the slowest queries in the regression tests,
this should help some little bit for buildfarm cycle times.
Back-patch to all supported branches, not so much because it's likely
that users will care much about the view's performance as because
tracking changes in the upstream IANA timezone code is really painful
if we don't keep all the branches in sync.
Discussion: https://postgr.es/m/27962.1493671706@sss.pgh.pa.us
2017-05-03 03:50:35 +02:00
|
|
|
}
|
|
|
|
|
2006-10-16 21:58:27 +02:00
|
|
|
/*
|
|
|
|
* Loop to split the given name into directory levels; for each level,
|
|
|
|
* search using scan_directory_ci().
|
|
|
|
*/
|
|
|
|
fname = name;
|
|
|
|
for (;;)
|
|
|
|
{
|
|
|
|
const char *slashptr;
|
2007-11-15 22:14:46 +01:00
|
|
|
int fnamelen;
|
2006-10-16 21:58:27 +02:00
|
|
|
|
|
|
|
slashptr = strchr(fname, '/');
|
|
|
|
if (slashptr)
|
|
|
|
fnamelen = slashptr - fname;
|
|
|
|
else
|
|
|
|
fnamelen = strlen(fname);
|
|
|
|
if (!scan_directory_ci(fullname, fname, fnamelen,
|
|
|
|
fullname + fullnamelen + 1,
|
|
|
|
MAXPGPATH - fullnamelen - 1))
|
|
|
|
return -1;
|
|
|
|
fullname[fullnamelen++] = '/';
|
|
|
|
fullnamelen += strlen(fullname + fullnamelen);
|
|
|
|
if (slashptr)
|
|
|
|
fname = slashptr + 1;
|
|
|
|
else
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (canonname)
|
|
|
|
strlcpy(canonname, fullname + orignamelen + 1, TZ_STRLEN_MAX + 1);
|
|
|
|
|
|
|
|
return open(fullname, O_RDONLY | PG_BINARY, 0);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Scan specified directory for a case-insensitive match to fname
|
2014-05-06 18:12:18 +02:00
|
|
|
* (of length fnamelen --- fname may not be null terminated!). If found,
|
2006-10-16 21:58:27 +02:00
|
|
|
* copy the actual filename into canonname and return true.
|
|
|
|
*/
|
|
|
|
static bool
|
|
|
|
scan_directory_ci(const char *dirname, const char *fname, int fnamelen,
|
|
|
|
char *canonname, int canonnamelen)
|
|
|
|
{
|
|
|
|
bool found = false;
|
|
|
|
DIR *dirdesc;
|
|
|
|
struct dirent *direntry;
|
|
|
|
|
|
|
|
dirdesc = AllocateDir(dirname);
|
|
|
|
|
Clean up assorted messiness around AllocateDir() usage.
This patch fixes a couple of low-probability bugs that could lead to
reporting an irrelevant errno value (and hence possibly a wrong SQLSTATE)
concerning directory-open or file-open failures. It also fixes places
where we took shortcuts in reporting such errors, either by using elog
instead of ereport or by using ereport but forgetting to specify an
errcode. And it eliminates a lot of just plain redundant error-handling
code.
In service of all this, export fd.c's formerly-static function
ReadDirExtended, so that external callers can make use of the coding
pattern
dir = AllocateDir(path);
while ((de = ReadDirExtended(dir, path, LOG)) != NULL)
if they'd like to treat directory-open failures as mere LOG conditions
rather than errors. Also fix FreeDir to be a no-op if we reach it
with dir == NULL, as such a coding pattern would cause.
Then, remove code at many call sites that was throwing an error or log
message for AllocateDir failure, as ReadDir or ReadDirExtended can handle
that job just fine. Aside from being a net code savings, this gets rid of
a lot of not-quite-up-to-snuff reports, as mentioned above. (In some
places these changes result in replacing a custom error message such as
"could not open tablespace directory" with more generic wording "could not
open directory", but it was agreed that the custom wording buys little as
long as we report the directory name.) In some other call sites where we
can't just remove code, change the error reports to be fully
project-style-compliant.
Also reorder code in restoreTwoPhaseData that was acquiring a lock
between AllocateDir and ReadDir; in the unlikely but surely not
impossible case that LWLockAcquire changes errno, AllocateDir failures
would be misreported. There is no great value in opening the directory
before acquiring TwoPhaseStateLock, so just do it in the other order.
Also fix CheckXLogRemoved to guarantee that it preserves errno,
as quite a number of call sites are implicitly assuming. (Again,
it's unlikely but I think not impossible that errno could change
during a SpinLockAcquire. If so, this function was broken for its
own purposes as well as breaking callers.)
And change a few places that were using not-per-project-style messages,
such as "could not read directory" when "could not open directory" is
more correct.
Back-patch the exporting of ReadDirExtended, in case we have occasion
to back-patch some fix that makes use of it; it's not needed right now
but surely making it global is pretty harmless. Also back-patch the
restoreTwoPhaseData and CheckXLogRemoved fixes. The rest of this is
essentially cosmetic and need not get back-patched.
Michael Paquier, with a bit of additional work by me
Discussion: https://postgr.es/m/CAB7nPqRpOCxjiirHmebEFhXVTK7V5Jvw4bz82p7Oimtsm3TyZA@mail.gmail.com
2017-12-04 23:02:52 +01:00
|
|
|
while ((direntry = ReadDirExtended(dirdesc, dirname, LOG)) != NULL)
|
2006-10-16 21:58:27 +02:00
|
|
|
{
|
|
|
|
/*
|
2014-05-06 18:12:18 +02:00
|
|
|
* Ignore . and .., plus any other "hidden" files. This is a security
|
2006-10-16 21:58:27 +02:00
|
|
|
* measure to prevent access to files outside the timezone directory.
|
|
|
|
*/
|
|
|
|
if (direntry->d_name[0] == '.')
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (strlen(direntry->d_name) == fnamelen &&
|
|
|
|
pg_strncasecmp(direntry->d_name, fname, fnamelen) == 0)
|
|
|
|
{
|
|
|
|
/* Found our match */
|
|
|
|
strlcpy(canonname, direntry->d_name, canonnamelen);
|
|
|
|
found = true;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
FreeDir(dirdesc);
|
|
|
|
|
|
|
|
return found;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2005-04-19 05:13:59 +02:00
|
|
|
/*
|
|
|
|
* We keep loaded timezones in a hashtable so we don't have to
|
2006-10-16 21:58:27 +02:00
|
|
|
* load and parse the TZ definition file every time one is selected.
|
|
|
|
* Because we want timezone names to be found case-insensitively,
|
|
|
|
* the hash key is the uppercased name of the zone.
|
2005-04-19 05:13:59 +02:00
|
|
|
*/
|
2006-10-16 21:58:27 +02:00
|
|
|
typedef struct
|
|
|
|
{
|
|
|
|
/* tznameupper contains the all-upper-case name of the timezone */
|
|
|
|
char tznameupper[TZ_STRLEN_MAX + 1];
|
|
|
|
pg_tz tz;
|
2007-11-15 23:25:18 +01:00
|
|
|
} pg_tz_cache;
|
2006-10-16 21:58:27 +02:00
|
|
|
|
2005-04-19 05:13:59 +02:00
|
|
|
static HTAB *timezone_cache = NULL;
|
2005-05-29 06:23:07 +02:00
|
|
|
|
2006-10-16 21:58:27 +02:00
|
|
|
|
2005-04-19 05:13:59 +02:00
|
|
|
static bool
|
|
|
|
init_timezone_hashtable(void)
|
|
|
|
{
|
|
|
|
HASHCTL hash_ctl;
|
|
|
|
|
|
|
|
MemSet(&hash_ctl, 0, sizeof(hash_ctl));
|
|
|
|
|
2005-09-09 04:31:50 +02:00
|
|
|
hash_ctl.keysize = TZ_STRLEN_MAX + 1;
|
2006-10-16 21:58:27 +02:00
|
|
|
hash_ctl.entrysize = sizeof(pg_tz_cache);
|
2005-04-19 05:13:59 +02:00
|
|
|
|
|
|
|
timezone_cache = hash_create("Timezones",
|
2005-06-27 01:32:34 +02:00
|
|
|
4,
|
2005-04-19 05:13:59 +02:00
|
|
|
&hash_ctl,
|
|
|
|
HASH_ELEM);
|
|
|
|
if (!timezone_cache)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Load a timezone from file or from cache.
|
|
|
|
* Does not verify that the timezone is acceptable!
|
2011-09-09 23:59:11 +02:00
|
|
|
*
|
|
|
|
* "GMT" is always interpreted as the tzparse() definition, without attempting
|
|
|
|
* to load a definition from the filesystem. This has a number of benefits:
|
|
|
|
* 1. It's guaranteed to succeed, so we don't have the failure mode wherein
|
|
|
|
* the bootstrap default timezone setting doesn't work (as could happen if
|
|
|
|
* the OS attempts to supply a leap-second-aware version of "GMT").
|
|
|
|
* 2. Because we aren't accessing the filesystem, we can safely initialize
|
|
|
|
* the "GMT" zone definition before my_exec_path is known.
|
|
|
|
* 3. It's quick enough that we don't waste much time when the bootstrap
|
|
|
|
* default timezone setting is later overridden from postgresql.conf.
|
2005-04-19 05:13:59 +02:00
|
|
|
*/
|
2011-09-09 23:59:11 +02:00
|
|
|
pg_tz *
|
2005-04-19 05:13:59 +02:00
|
|
|
pg_tzset(const char *name)
|
|
|
|
{
|
2006-10-16 21:58:27 +02:00
|
|
|
pg_tz_cache *tzp;
|
|
|
|
struct state tzstate;
|
|
|
|
char uppername[TZ_STRLEN_MAX + 1];
|
|
|
|
char canonname[TZ_STRLEN_MAX + 1];
|
|
|
|
char *p;
|
2005-10-15 04:49:52 +02:00
|
|
|
|
2005-09-09 04:31:50 +02:00
|
|
|
if (strlen(name) > TZ_STRLEN_MAX)
|
2005-04-19 05:13:59 +02:00
|
|
|
return NULL; /* not going to fit */
|
|
|
|
|
|
|
|
if (!timezone_cache)
|
|
|
|
if (!init_timezone_hashtable())
|
|
|
|
return NULL;
|
|
|
|
|
2006-10-16 21:58:27 +02:00
|
|
|
/*
|
|
|
|
* Upcase the given name to perform a case-insensitive hashtable search.
|
|
|
|
* (We could alternatively downcase it, but we prefer upcase so that we
|
2007-11-15 22:14:46 +01:00
|
|
|
* can get consistently upcased results from tzparse() in case the name is
|
|
|
|
* a POSIX-style timezone spec.)
|
2006-10-16 21:58:27 +02:00
|
|
|
*/
|
|
|
|
p = uppername;
|
|
|
|
while (*name)
|
|
|
|
*p++ = pg_toupper((unsigned char) *name++);
|
|
|
|
*p = '\0';
|
|
|
|
|
|
|
|
tzp = (pg_tz_cache *) hash_search(timezone_cache,
|
|
|
|
uppername,
|
|
|
|
HASH_FIND,
|
|
|
|
NULL);
|
2005-04-19 05:13:59 +02:00
|
|
|
if (tzp)
|
2005-05-29 06:23:07 +02:00
|
|
|
{
|
2005-04-19 05:13:59 +02:00
|
|
|
/* Timezone found in cache, nothing more to do */
|
2006-10-16 21:58:27 +02:00
|
|
|
return &tzp->tz;
|
2005-05-29 06:23:07 +02:00
|
|
|
}
|
2005-04-19 05:13:59 +02:00
|
|
|
|
2011-09-09 23:59:11 +02:00
|
|
|
/*
|
|
|
|
* "GMT" is always sent to tzparse(), as per discussion above.
|
|
|
|
*/
|
|
|
|
if (strcmp(uppername, "GMT") == 0)
|
|
|
|
{
|
2016-03-28 23:19:29 +02:00
|
|
|
if (!tzparse(uppername, &tzstate, true))
|
2011-09-09 23:59:11 +02:00
|
|
|
{
|
|
|
|
/* This really, really should not happen ... */
|
|
|
|
elog(ERROR, "could not initialize GMT time zone");
|
|
|
|
}
|
|
|
|
/* Use uppercase name as canonical */
|
|
|
|
strcpy(canonname, uppername);
|
|
|
|
}
|
2016-03-28 21:10:17 +02:00
|
|
|
else if (tzload(uppername, canonname, &tzstate, true) != 0)
|
2005-04-19 05:13:59 +02:00
|
|
|
{
|
2016-03-28 23:19:29 +02:00
|
|
|
if (uppername[0] == ':' || !tzparse(uppername, &tzstate, false))
|
2005-05-29 06:23:07 +02:00
|
|
|
{
|
2005-04-19 05:13:59 +02:00
|
|
|
/* Unknown timezone. Fail our call instead of loading GMT! */
|
|
|
|
return NULL;
|
2005-05-29 06:23:07 +02:00
|
|
|
}
|
2006-10-16 21:58:27 +02:00
|
|
|
/* For POSIX timezone specs, use uppercase name as canonical */
|
|
|
|
strcpy(canonname, uppername);
|
2005-04-19 05:13:59 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Save timezone in the cache */
|
2006-10-16 21:58:27 +02:00
|
|
|
tzp = (pg_tz_cache *) hash_search(timezone_cache,
|
|
|
|
uppername,
|
|
|
|
HASH_ENTER,
|
|
|
|
NULL);
|
2005-10-15 04:49:52 +02:00
|
|
|
|
2006-10-16 21:58:27 +02:00
|
|
|
/* hash_search already copied uppername into the hash key */
|
|
|
|
strcpy(tzp->tz.TZname, canonname);
|
|
|
|
memcpy(&tzp->tz.state, &tzstate, sizeof(tzstate));
|
2005-04-19 05:13:59 +02:00
|
|
|
|
2006-10-16 21:58:27 +02:00
|
|
|
return &tzp->tz;
|
2005-04-19 05:13:59 +02:00
|
|
|
}
|
|
|
|
|
Fix some odd behaviors when using a SQL-style simple GMT offset timezone.
Formerly, when using a SQL-spec timezone setting with a fixed GMT offset
(called a "brute force" timezone in the code), the session_timezone
variable was not updated to match the nominal timezone; rather, all code
was expected to ignore session_timezone if HasCTZSet was true. This is
of course obviously fragile, though a search of the code finds only
timeofday() failing to honor the rule. A bigger problem was that
DetermineTimeZoneOffset() supposed that if its pg_tz parameter was
pointer-equal to session_timezone, then HasCTZSet should override the
parameter. This would cause datetime input containing an explicit zone
name to be treated as referencing the brute-force zone instead, if the
zone name happened to match the session timezone that had prevailed
before installing the brute-force zone setting (as reported in bug #8572).
The same malady could affect AT TIME ZONE operators.
To fix, set up session_timezone so that it matches the brute-force zone
specification, which we can do using the POSIX timezone definition syntax
"<abbrev>offset", and get rid of the bogus lookaside check in
DetermineTimeZoneOffset(). Aside from fixing the erroneous behavior in
datetime parsing and AT TIME ZONE, this will cause the timeofday() function
to print its result in the user-requested time zone rather than some
previously-set zone. It might also affect results in third-party
extensions, if there are any that make use of session_timezone without
considering HasCTZSet, but in all cases the new behavior should be saner
than before.
Back-patch to all supported branches.
2013-11-01 17:13:18 +01:00
|
|
|
/*
|
|
|
|
* Load a fixed-GMT-offset timezone.
|
|
|
|
* This is used for SQL-spec SET TIME ZONE INTERVAL 'foo' cases.
|
|
|
|
* It's otherwise equivalent to pg_tzset().
|
|
|
|
*
|
|
|
|
* The GMT offset is specified in seconds, positive values meaning west of
|
|
|
|
* Greenwich (ie, POSIX not ISO sign convention). However, we use ISO
|
|
|
|
* sign convention in the displayable abbreviation for the zone.
|
2014-07-22 04:41:20 +02:00
|
|
|
*
|
|
|
|
* Caution: this can fail (return NULL) if the specified offset is outside
|
|
|
|
* the range allowed by the zic library.
|
Fix some odd behaviors when using a SQL-style simple GMT offset timezone.
Formerly, when using a SQL-spec timezone setting with a fixed GMT offset
(called a "brute force" timezone in the code), the session_timezone
variable was not updated to match the nominal timezone; rather, all code
was expected to ignore session_timezone if HasCTZSet was true. This is
of course obviously fragile, though a search of the code finds only
timeofday() failing to honor the rule. A bigger problem was that
DetermineTimeZoneOffset() supposed that if its pg_tz parameter was
pointer-equal to session_timezone, then HasCTZSet should override the
parameter. This would cause datetime input containing an explicit zone
name to be treated as referencing the brute-force zone instead, if the
zone name happened to match the session timezone that had prevailed
before installing the brute-force zone setting (as reported in bug #8572).
The same malady could affect AT TIME ZONE operators.
To fix, set up session_timezone so that it matches the brute-force zone
specification, which we can do using the POSIX timezone definition syntax
"<abbrev>offset", and get rid of the bogus lookaside check in
DetermineTimeZoneOffset(). Aside from fixing the erroneous behavior in
datetime parsing and AT TIME ZONE, this will cause the timeofday() function
to print its result in the user-requested time zone rather than some
previously-set zone. It might also affect results in third-party
extensions, if there are any that make use of session_timezone without
considering HasCTZSet, but in all cases the new behavior should be saner
than before.
Back-patch to all supported branches.
2013-11-01 17:13:18 +01:00
|
|
|
*/
|
|
|
|
pg_tz *
|
|
|
|
pg_tzset_offset(long gmtoffset)
|
|
|
|
{
|
|
|
|
long absoffset = (gmtoffset < 0) ? -gmtoffset : gmtoffset;
|
|
|
|
char offsetstr[64];
|
|
|
|
char tzname[128];
|
|
|
|
|
|
|
|
snprintf(offsetstr, sizeof(offsetstr),
|
2017-04-30 21:13:51 +02:00
|
|
|
"%02ld", absoffset / SECS_PER_HOUR);
|
|
|
|
absoffset %= SECS_PER_HOUR;
|
Fix some odd behaviors when using a SQL-style simple GMT offset timezone.
Formerly, when using a SQL-spec timezone setting with a fixed GMT offset
(called a "brute force" timezone in the code), the session_timezone
variable was not updated to match the nominal timezone; rather, all code
was expected to ignore session_timezone if HasCTZSet was true. This is
of course obviously fragile, though a search of the code finds only
timeofday() failing to honor the rule. A bigger problem was that
DetermineTimeZoneOffset() supposed that if its pg_tz parameter was
pointer-equal to session_timezone, then HasCTZSet should override the
parameter. This would cause datetime input containing an explicit zone
name to be treated as referencing the brute-force zone instead, if the
zone name happened to match the session timezone that had prevailed
before installing the brute-force zone setting (as reported in bug #8572).
The same malady could affect AT TIME ZONE operators.
To fix, set up session_timezone so that it matches the brute-force zone
specification, which we can do using the POSIX timezone definition syntax
"<abbrev>offset", and get rid of the bogus lookaside check in
DetermineTimeZoneOffset(). Aside from fixing the erroneous behavior in
datetime parsing and AT TIME ZONE, this will cause the timeofday() function
to print its result in the user-requested time zone rather than some
previously-set zone. It might also affect results in third-party
extensions, if there are any that make use of session_timezone without
considering HasCTZSet, but in all cases the new behavior should be saner
than before.
Back-patch to all supported branches.
2013-11-01 17:13:18 +01:00
|
|
|
if (absoffset != 0)
|
|
|
|
{
|
|
|
|
snprintf(offsetstr + strlen(offsetstr),
|
|
|
|
sizeof(offsetstr) - strlen(offsetstr),
|
2017-04-30 21:13:51 +02:00
|
|
|
":%02ld", absoffset / SECS_PER_MINUTE);
|
|
|
|
absoffset %= SECS_PER_MINUTE;
|
Fix some odd behaviors when using a SQL-style simple GMT offset timezone.
Formerly, when using a SQL-spec timezone setting with a fixed GMT offset
(called a "brute force" timezone in the code), the session_timezone
variable was not updated to match the nominal timezone; rather, all code
was expected to ignore session_timezone if HasCTZSet was true. This is
of course obviously fragile, though a search of the code finds only
timeofday() failing to honor the rule. A bigger problem was that
DetermineTimeZoneOffset() supposed that if its pg_tz parameter was
pointer-equal to session_timezone, then HasCTZSet should override the
parameter. This would cause datetime input containing an explicit zone
name to be treated as referencing the brute-force zone instead, if the
zone name happened to match the session timezone that had prevailed
before installing the brute-force zone setting (as reported in bug #8572).
The same malady could affect AT TIME ZONE operators.
To fix, set up session_timezone so that it matches the brute-force zone
specification, which we can do using the POSIX timezone definition syntax
"<abbrev>offset", and get rid of the bogus lookaside check in
DetermineTimeZoneOffset(). Aside from fixing the erroneous behavior in
datetime parsing and AT TIME ZONE, this will cause the timeofday() function
to print its result in the user-requested time zone rather than some
previously-set zone. It might also affect results in third-party
extensions, if there are any that make use of session_timezone without
considering HasCTZSet, but in all cases the new behavior should be saner
than before.
Back-patch to all supported branches.
2013-11-01 17:13:18 +01:00
|
|
|
if (absoffset != 0)
|
|
|
|
snprintf(offsetstr + strlen(offsetstr),
|
|
|
|
sizeof(offsetstr) - strlen(offsetstr),
|
|
|
|
":%02ld", absoffset);
|
|
|
|
}
|
|
|
|
if (gmtoffset > 0)
|
|
|
|
snprintf(tzname, sizeof(tzname), "<-%s>+%s",
|
|
|
|
offsetstr, offsetstr);
|
|
|
|
else
|
|
|
|
snprintf(tzname, sizeof(tzname), "<+%s>-%s",
|
|
|
|
offsetstr, offsetstr);
|
|
|
|
|
|
|
|
return pg_tzset(tzname);
|
|
|
|
}
|
|
|
|
|
2005-04-19 05:13:59 +02:00
|
|
|
|
2004-05-21 07:08:06 +02:00
|
|
|
/*
|
|
|
|
* Initialize timezone library
|
|
|
|
*
|
2011-09-09 23:59:11 +02:00
|
|
|
* This is called before GUC variable initialization begins. Its purpose
|
|
|
|
* is to ensure that log_timezone has a valid value before any logging GUC
|
|
|
|
* variables could become set to values that require elog.c to provide
|
2014-05-06 18:12:18 +02:00
|
|
|
* timestamps (e.g., log_line_prefix). We may as well initialize
|
2019-08-13 06:53:41 +02:00
|
|
|
* session_timezone to something valid, too.
|
2004-05-21 07:08:06 +02:00
|
|
|
*/
|
2004-05-21 14:30:25 +02:00
|
|
|
void
|
|
|
|
pg_timezone_initialize(void)
|
|
|
|
{
|
Split PGC_S_DEFAULT into two values, for true boot_val vs computed default.
Failure to distinguish these cases is the real cause behind the recent
reports of Windows builds crashing on 'infinity'::timestamp, which was
directly due to failure to establish a value of timezone_abbreviations
in postmaster child processes. The postmaster had the desired value,
but write_one_nondefault_variable() didn't transmit it to backends.
To fix that, invent a new value PGC_S_DYNAMIC_DEFAULT, and be sure to use
that or PGC_S_ENV_VAR (as appropriate) for "default" settings that are
computed during initialization. (We need both because there's at least
one variable that could receive a value from either source.)
This commit also fixes ProcessConfigFile's failure to restore the correct
default value for certain GUC variables if they are set in postgresql.conf
and then removed/commented out of the file. We have to recompute and
reinstall the value for any GUC variable that could have received a value
from PGC_S_DYNAMIC_DEFAULT or PGC_S_ENV_VAR sources, and there were a
number of oversights. (That whole thing is a crock that needs to be
redesigned, but not today.)
However, I intentionally didn't make it work "exactly right" for the cases
of timezone and log_timezone. The exactly right behavior would involve
running select_default_timezone, which we'd have to do independently in
each postgres process, causing the whole database to become entirely
unresponsive for as much as several seconds. That didn't seem like a good
idea, especially since the variable's removal from postgresql.conf might be
just an accidental edit. Instead the behavior is to adopt the previously
active setting as if it were default.
Note that this patch creates an ABI break for extensions that use any of
the PGC_S_XXX constants; they'll need to be recompiled.
2011-05-12 01:57:38 +02:00
|
|
|
/*
|
2011-09-09 23:59:11 +02:00
|
|
|
* We may not yet know where PGSHAREDIR is (in particular this is true in
|
2012-06-10 21:20:04 +02:00
|
|
|
* an EXEC_BACKEND subprocess). So use "GMT", which pg_tzset forces to be
|
|
|
|
* interpreted without reference to the filesystem. This corresponds to
|
|
|
|
* the bootstrap default for these variables in guc.c, although in
|
2011-09-09 23:59:11 +02:00
|
|
|
* principle it could be different.
|
Split PGC_S_DEFAULT into two values, for true boot_val vs computed default.
Failure to distinguish these cases is the real cause behind the recent
reports of Windows builds crashing on 'infinity'::timestamp, which was
directly due to failure to establish a value of timezone_abbreviations
in postmaster child processes. The postmaster had the desired value,
but write_one_nondefault_variable() didn't transmit it to backends.
To fix that, invent a new value PGC_S_DYNAMIC_DEFAULT, and be sure to use
that or PGC_S_ENV_VAR (as appropriate) for "default" settings that are
computed during initialization. (We need both because there's at least
one variable that could receive a value from either source.)
This commit also fixes ProcessConfigFile's failure to restore the correct
default value for certain GUC variables if they are set in postgresql.conf
and then removed/commented out of the file. We have to recompute and
reinstall the value for any GUC variable that could have received a value
from PGC_S_DYNAMIC_DEFAULT or PGC_S_ENV_VAR sources, and there were a
number of oversights. (That whole thing is a crock that needs to be
redesigned, but not today.)
However, I intentionally didn't make it work "exactly right" for the cases
of timezone and log_timezone. The exactly right behavior would involve
running select_default_timezone, which we'd have to do independently in
each postgres process, causing the whole database to become entirely
unresponsive for as much as several seconds. That didn't seem like a good
idea, especially since the variable's removal from postgresql.conf might be
just an accidental edit. Instead the behavior is to adopt the previously
active setting as if it were default.
Note that this patch creates an ABI break for extensions that use any of
the PGC_S_XXX constants; they'll need to be recompiled.
2011-05-12 01:57:38 +02:00
|
|
|
*/
|
2011-09-09 23:59:11 +02:00
|
|
|
session_timezone = pg_tzset("GMT");
|
|
|
|
log_timezone = session_timezone;
|
2004-05-21 07:08:06 +02:00
|
|
|
}
|
2006-09-16 22:14:34 +02:00
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Functions to enumerate available timezones
|
|
|
|
*
|
|
|
|
* Note that pg_tzenumerate_next() will return a pointer into the pg_tzenum
|
|
|
|
* structure, so the data is only valid up to the next call.
|
|
|
|
*
|
|
|
|
* All data is allocated using palloc in the current context.
|
|
|
|
*/
|
|
|
|
#define MAX_TZDIR_DEPTH 10
|
|
|
|
|
2006-10-04 02:30:14 +02:00
|
|
|
struct pg_tzenum
|
|
|
|
{
|
|
|
|
int baselen;
|
|
|
|
int depth;
|
|
|
|
DIR *dirdesc[MAX_TZDIR_DEPTH];
|
|
|
|
char *dirname[MAX_TZDIR_DEPTH];
|
|
|
|
struct pg_tz tz;
|
2006-09-16 22:14:34 +02:00
|
|
|
};
|
2006-10-04 02:30:14 +02:00
|
|
|
|
2006-09-16 22:14:34 +02:00
|
|
|
/* typedef pg_tzenum is declared in pgtime.h */
|
|
|
|
|
|
|
|
pg_tzenum *
|
2006-10-04 02:30:14 +02:00
|
|
|
pg_tzenumerate_start(void)
|
2006-09-16 22:14:34 +02:00
|
|
|
{
|
2006-10-04 02:30:14 +02:00
|
|
|
pg_tzenum *ret = (pg_tzenum *) palloc0(sizeof(pg_tzenum));
|
|
|
|
char *startdir = pstrdup(pg_TZDIR());
|
2006-09-16 22:14:34 +02:00
|
|
|
|
|
|
|
ret->baselen = strlen(startdir) + 1;
|
|
|
|
ret->depth = 0;
|
|
|
|
ret->dirname[0] = startdir;
|
|
|
|
ret->dirdesc[0] = AllocateDir(startdir);
|
2006-10-04 02:30:14 +02:00
|
|
|
if (!ret->dirdesc[0])
|
2006-09-16 22:14:34 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
(errcode_for_file_access(),
|
|
|
|
errmsg("could not open directory \"%s\": %m", startdir)));
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
pg_tzenumerate_end(pg_tzenum *dir)
|
|
|
|
{
|
|
|
|
while (dir->depth >= 0)
|
|
|
|
{
|
|
|
|
FreeDir(dir->dirdesc[dir->depth]);
|
|
|
|
pfree(dir->dirname[dir->depth]);
|
|
|
|
dir->depth--;
|
|
|
|
}
|
|
|
|
pfree(dir);
|
|
|
|
}
|
|
|
|
|
|
|
|
pg_tz *
|
|
|
|
pg_tzenumerate_next(pg_tzenum *dir)
|
|
|
|
{
|
|
|
|
while (dir->depth >= 0)
|
|
|
|
{
|
|
|
|
struct dirent *direntry;
|
2017-04-11 20:13:31 +02:00
|
|
|
char fullname[MAXPGPATH * 2];
|
2006-09-16 22:14:34 +02:00
|
|
|
struct stat statbuf;
|
|
|
|
|
|
|
|
direntry = ReadDir(dir->dirdesc[dir->depth], dir->dirname[dir->depth]);
|
|
|
|
|
|
|
|
if (!direntry)
|
|
|
|
{
|
|
|
|
/* End of this directory */
|
|
|
|
FreeDir(dir->dirdesc[dir->depth]);
|
|
|
|
pfree(dir->dirname[dir->depth]);
|
|
|
|
dir->depth--;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (direntry->d_name[0] == '.')
|
|
|
|
continue;
|
|
|
|
|
2017-04-11 20:13:31 +02:00
|
|
|
snprintf(fullname, sizeof(fullname), "%s/%s",
|
2006-09-16 22:14:34 +02:00
|
|
|
dir->dirname[dir->depth], direntry->d_name);
|
|
|
|
if (stat(fullname, &statbuf) != 0)
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode_for_file_access(),
|
|
|
|
errmsg("could not stat \"%s\": %m", fullname)));
|
|
|
|
|
|
|
|
if (S_ISDIR(statbuf.st_mode))
|
|
|
|
{
|
|
|
|
/* Step into the subdirectory */
|
2006-10-04 02:30:14 +02:00
|
|
|
if (dir->depth >= MAX_TZDIR_DEPTH - 1)
|
2006-09-16 22:14:34 +02:00
|
|
|
ereport(ERROR,
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
|
|
|
(errmsg_internal("timezone directory stack overflow")));
|
2006-09-16 22:14:34 +02:00
|
|
|
dir->depth++;
|
|
|
|
dir->dirname[dir->depth] = pstrdup(fullname);
|
|
|
|
dir->dirdesc[dir->depth] = AllocateDir(fullname);
|
2006-10-04 02:30:14 +02:00
|
|
|
if (!dir->dirdesc[dir->depth])
|
2006-09-16 22:14:34 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
(errcode_for_file_access(),
|
|
|
|
errmsg("could not open directory \"%s\": %m",
|
|
|
|
fullname)));
|
|
|
|
|
|
|
|
/* Start over reading in the new directory */
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2006-10-04 02:30:14 +02:00
|
|
|
* Load this timezone using tzload() not pg_tzset(), so we don't fill
|
Improve performance of timezone loading, especially pg_timezone_names view.
tzparse() would attempt to load the "posixrules" timezone database file on
each call. That might seem like it would only be an issue when selecting a
POSIX-style zone name rather than a zone defined in the timezone database,
but it turns out that each zone definition file contains a POSIX-style zone
string and tzload() will call tzparse() to parse that. Thus, when scanning
the whole timezone file tree as we do in the pg_timezone_names view,
"posixrules" was read repetitively for each zone definition file. Fix
that by caching the file on first use within any given process. (We cache
other zone definitions for the life of the process, so there seems little
reason not to cache this one as well.) This probably won't help much in
processes that never run pg_timezone_names, but even one additional SET
of the timezone GUC would come out ahead.
An even worse problem for pg_timezone_names is that pg_open_tzfile()
has an inefficient way of identifying the canonical case of a zone name:
it basically re-descends the directory tree to the zone file. That's not
awful for an individual "SET timezone" operation, but it's pretty horrid
when we're inspecting every zone in the database. And it's pointless too
because we already know the canonical spelling, having just read it from
the filesystem. Fix by teaching pg_open_tzfile() to avoid the directory
search if it's not asked for the canonical name, and backfilling the
proper result in pg_tzenumerate_next().
In combination these changes seem to make the pg_timezone_names view
about 3x faster to read, for me. Since a scan of pg_timezone_names
has up to now been one of the slowest queries in the regression tests,
this should help some little bit for buildfarm cycle times.
Back-patch to all supported branches, not so much because it's likely
that users will care much about the view's performance as because
tracking changes in the upstream IANA timezone code is really painful
if we don't keep all the branches in sync.
Discussion: https://postgr.es/m/27962.1493671706@sss.pgh.pa.us
2017-05-03 03:50:35 +02:00
|
|
|
* the cache. Also, don't ask for the canonical spelling: we already
|
|
|
|
* know it, and pg_open_tzfile's way of finding it out is pretty
|
|
|
|
* inefficient.
|
2006-09-16 22:14:34 +02:00
|
|
|
*/
|
Improve performance of timezone loading, especially pg_timezone_names view.
tzparse() would attempt to load the "posixrules" timezone database file on
each call. That might seem like it would only be an issue when selecting a
POSIX-style zone name rather than a zone defined in the timezone database,
but it turns out that each zone definition file contains a POSIX-style zone
string and tzload() will call tzparse() to parse that. Thus, when scanning
the whole timezone file tree as we do in the pg_timezone_names view,
"posixrules" was read repetitively for each zone definition file. Fix
that by caching the file on first use within any given process. (We cache
other zone definitions for the life of the process, so there seems little
reason not to cache this one as well.) This probably won't help much in
processes that never run pg_timezone_names, but even one additional SET
of the timezone GUC would come out ahead.
An even worse problem for pg_timezone_names is that pg_open_tzfile()
has an inefficient way of identifying the canonical case of a zone name:
it basically re-descends the directory tree to the zone file. That's not
awful for an individual "SET timezone" operation, but it's pretty horrid
when we're inspecting every zone in the database. And it's pointless too
because we already know the canonical spelling, having just read it from
the filesystem. Fix by teaching pg_open_tzfile() to avoid the directory
search if it's not asked for the canonical name, and backfilling the
proper result in pg_tzenumerate_next().
In combination these changes seem to make the pg_timezone_names view
about 3x faster to read, for me. Since a scan of pg_timezone_names
has up to now been one of the slowest queries in the regression tests,
this should help some little bit for buildfarm cycle times.
Back-patch to all supported branches, not so much because it's likely
that users will care much about the view's performance as because
tracking changes in the upstream IANA timezone code is really painful
if we don't keep all the branches in sync.
Discussion: https://postgr.es/m/27962.1493671706@sss.pgh.pa.us
2017-05-03 03:50:35 +02:00
|
|
|
if (tzload(fullname + dir->baselen, NULL, &dir->tz.state, true) != 0)
|
2006-09-16 22:14:34 +02:00
|
|
|
{
|
|
|
|
/* Zone could not be loaded, ignore it */
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2011-09-09 23:59:11 +02:00
|
|
|
if (!pg_tz_acceptable(&dir->tz))
|
2008-11-13 21:49:38 +01:00
|
|
|
{
|
|
|
|
/* Ignore leap-second zones */
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
Improve performance of timezone loading, especially pg_timezone_names view.
tzparse() would attempt to load the "posixrules" timezone database file on
each call. That might seem like it would only be an issue when selecting a
POSIX-style zone name rather than a zone defined in the timezone database,
but it turns out that each zone definition file contains a POSIX-style zone
string and tzload() will call tzparse() to parse that. Thus, when scanning
the whole timezone file tree as we do in the pg_timezone_names view,
"posixrules" was read repetitively for each zone definition file. Fix
that by caching the file on first use within any given process. (We cache
other zone definitions for the life of the process, so there seems little
reason not to cache this one as well.) This probably won't help much in
processes that never run pg_timezone_names, but even one additional SET
of the timezone GUC would come out ahead.
An even worse problem for pg_timezone_names is that pg_open_tzfile()
has an inefficient way of identifying the canonical case of a zone name:
it basically re-descends the directory tree to the zone file. That's not
awful for an individual "SET timezone" operation, but it's pretty horrid
when we're inspecting every zone in the database. And it's pointless too
because we already know the canonical spelling, having just read it from
the filesystem. Fix by teaching pg_open_tzfile() to avoid the directory
search if it's not asked for the canonical name, and backfilling the
proper result in pg_tzenumerate_next().
In combination these changes seem to make the pg_timezone_names view
about 3x faster to read, for me. Since a scan of pg_timezone_names
has up to now been one of the slowest queries in the regression tests,
this should help some little bit for buildfarm cycle times.
Back-patch to all supported branches, not so much because it's likely
that users will care much about the view's performance as because
tracking changes in the upstream IANA timezone code is really painful
if we don't keep all the branches in sync.
Discussion: https://postgr.es/m/27962.1493671706@sss.pgh.pa.us
2017-05-03 03:50:35 +02:00
|
|
|
/* OK, return the canonical zone name spelling. */
|
|
|
|
strlcpy(dir->tz.TZname, fullname + dir->baselen,
|
|
|
|
sizeof(dir->tz.TZname));
|
|
|
|
|
2006-09-16 22:14:34 +02:00
|
|
|
/* Timezone loaded OK. */
|
|
|
|
return &dir->tz;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Nothing more found */
|
|
|
|
return NULL;
|
|
|
|
}
|