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

Reply via email to