| From: | Jim Nasby <jim(at)nasby(dot)net> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Christopher Browne <cbbrowne(at)gmail(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, "alvherre(at)alvh(dot)no-ip(dot)org Herrera" <alvherre(at)alvh(dot)no-ip(dot)org>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: storing TZ along timestamps |
| Date: | 2011-07-26 22:45:57 |
| Message-ID: | 36920C89-358A-4901-8AC0-D00EDFC8C31F@nasby.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Jul 25, 2011, at 6:22 PM, Robert Haas wrote:
> On Mon, Jul 25, 2011 at 6:26 PM, Jim Nasby <jim(at)nasby(dot)net> wrote:
>> Hrm, don't we only pull in ZIC info on a reload? Or do we actually refer to it dynamically all the time? Perhaps we can enforce that we'll only recognize new TZ info as part of a config reload?
>
> Hmm. That might work in theory, but I don't see any good way to
> update every database's tz table on each reload.
I'm assuming that the issue here is that multiple backends could be connected to the same database, and we don't want all of them to try to actually do the updates, only the first one that discovers the change. If that's the problem you foresee then perhaps it's a non-issue... if each backend only updates things that have actually changed, and they do that with race-free 'merge' logic, then only the first backend to attempt the update would end up finding actual work to do.
Or are you seeing a problem I'm missing?
--
Jim C. Nasby, Database Architect jim(at)nasby(dot)net
512.569.9461 (cell) http://jim.nasby.net
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Christopher Browne | 2011-07-26 22:56:46 | Re: storing TZ along timestamps |
| Previous Message | David Fetter | 2011-07-26 22:13:40 | Re: [COMMITTERS] pgsql: Add missing newlines at end of error messages |