Re: storing TZ along timestamps

On Jul 26, 2011, at 5:56 PM, Christopher Browne wrote:
>> 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?
>
> What if 4 backends concurrently are the "first ones" to try to
> simultaneously add "South America/Ruritania", and...
>
> 1. Connection #1 came in 'first', but rolls back its transaction.
> 2. Connection #2 came in 'second', and also winds up rolling back its
> transaction because the connection fails due to a network problem.
> 3. Connection #3 actually completes. But doesn't commit until after #4.
> 4. Connection #4 started last, but turns out to COMMIT first.

Ugh, I didn't realize that a reload would take effect in the middle of a transaction. That certainly kills what I proposed.

Though, now I'm wondering why this info would need to be in every database anyway... certainly this should be treated as global data, and if that's the case then only one process needs to update it. Though I'm not sure if it's possible for global data to be ACID.

Anyway, rather than continue this on-list, I'm going to get Alvaro to think about it in more detail and see what he comes up with.
--
Jim C. Nasby, Database Architect jim(at)nasby(dot)net
512.569.9461 (cell) http://jim.nasby.net