See the archived thread here: http://www.postgresql.org/message-id/CAEghcWD8DXjroBYCZsdGrx+cHTCbCbW9es2uQ+o7a8NZ61JT=q...@mail.gmail.com
Short version: Sorry, but you're going to need to recompile if you want that behavior. Here's a diff applied against 9.2.1 http://pastebin.com/5AyaX2RF. I've deployed the patched version a couple dozen times now and it is working flawlessly. T.J. On Wed, Feb 6, 2013 at 1:32 PM, Igor Neyman <iney...@perceptron.com> wrote: > Timezone configuration parameter (defaulting to system timezone) worked > fine for us before upgrading from 8.4. to 9.2.**** > > ** ** > > Now we’ve got a problem. **** > > 9.2 Release Notes says:**** > > · Identify the server time zone during initdb, and set postgresql.confentries > timezone<http://www.postgresql.org/docs/9.2/static/runtime-config-client.html#GUC-TIMEZONE>and > log_timezone<http://www.postgresql.org/docs/9.2/static/runtime-config-logging.html#GUC-LOG-TIMEZONE>accordingly > (Tom Lane) > **** > > This avoids expensive time zone probes during server start.**** > > ** ** > > Question: is there any way to revert back to old behavior so that server > will probe system’s timezone on startup (default to OS timezone on startup) > instead setting it during initdb?**** > > Obviously, without recompiling/rebuilding Postgres.**** > > ** ** > > I’m dealing with the situation, where system is being built in one > timezone (could be anywhere around the globe), and then moved to other (not > known during system build) location with different timezone. **** > > After relocation, OS timezone will change, but we can’t allow user to edit > timezone parameter in Postgresql.conf.**** > > ** ** > > Regards,**** > > Igor Neyman**** >
