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
