Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Thu, May 19, 2011 at 12:19 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> What would make everybody happy is to find a way of identifying the
>> system timezone that isn't such a massive, expensive kluge. Any ideas?
> ...reads the code...
> Good grief. What an incredibly ugly hack. Is there seriously no
> portable way of doing this?
AFAIK, not. The info is certainly not available in the POSIX/SUS spec,
probably because they don't think there's a standardized idea of what
timezone names are to begin with.
(There was some discussion just a week or two ago in the Fedora lists
about this, but I fear Lennart Poettering suffers from a seriously
inflated view of his ability to establish standards without bothering
with any actual, um, standards process.)
> If not, then how about jiggering things somehow so that only one
> server process needs to run the hack? Perhaps it can drop the result
> in a file or shared memory or something from which the remaining
> backends can read it out without having to redo all that work?
> Admittedly there is a synchronization problem there I'm not quite sure
> how to solve.
Well, the main point in my mind is that the process is so damn expensive
that we don't want to run it at all, ever, if we can avoid it.
We could imagine launching a postmaster child to compute the result,
as you suggest. And it would work 99.9% of the time, because probably
nobody would remove the setting from postgresql.conf within a few
seconds of having started the postmaster. But also, 99.999% of the time
it would be completely wasted effort because the DBA wouldn't remove the
postgresql.conf setting at all, ever.
regards, tom lane
In response to
pgsql-hackers by date
|Next:||From: Robert Haas||Date: 2011-05-23 02:12:31|
|Subject: Re: timezone GUC|
|Previous:||From: Bruce Momjian||Date: 2011-05-23 01:39:38|
|Subject: Re: [BUGS] BUG #6034: pg_upgrade fails when it should not.|