On Thu, May 19, 2011 at 12:19 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Thu, May 19, 2011 at 12:12 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> We could do that, but the issue that this code is trying to avoid is >>> that identify_system_timezone can easily add several seconds to the >>> postmaster startup time. So one of the reasons why someone would be >>> putting a timezone setting into postgresql.conf in the first place is >>> to not pay that startup overhead. I'm not thrilled with the idea >>> of defeating that in order to cover the corner case where they remove >>> the setting later. > >> Yeah, I'm not thrilled with that either. However, I'm also not >> thrilled with the existing behavior. Consistency is the hobgoblin of >> small minds, and also mine. > > 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? 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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
