On Fri, Jun 11, 2004 at 01:49:18PM -0400, Tom Lane wrote: > Steve Atkins <[EMAIL PROTECTED]> writes: > > Uhm... only updates within the current transaction. So if you merge the > > global state and the local state that's exactly what you'll see. > > The only way this would work is if at every SetQuerySnapshot() you copy > *all* of the global variables as part of the snapshot. You'd have to > copy them all since you don't know which ones you'll need for the next > query. To avoid race conditions, you'd need to lock out transaction > commits while you are doing this copying.
Yup, though that's going to be acquire lock, memcpy, release lock and there's unlikely to be more than a few hundred bytes of state. > I think there are also race conditions involved in transaction commit, > since there's no way to make the update of the global state be atomic > with the actual transaction commit ... unless perhaps you want to hold > a lock on the global state area while committing. Yeah, that's the implementation detail that's going to really kill the idea in most cases. > All in all, I think the overhead of this scheme would be enormous. It > implies significant costs during every transaction start and commit, > whether or not that transaction is getting any benefit. I think you're right, but it was interesting to consider briefly. Cheers, Steve ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org