From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Jochem van Dieten <jochemd(at)oli(dot)tudelft(dot)nl> |
Cc: | Manfred Koizar <mkoi-pg(at)aon(dot)at>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: planner/optimizer question |
Date: | 2004-05-01 16:21:28 |
Message-ID: | 14614.1083428488@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Jochem van Dieten <jochemd(at)oli(dot)tudelft(dot)nl> writes:
> The moment the heap tuple is updated/deleted the visible-to-all
> flag needs to be set to false again in all indexes. This is
> critical,
Exactly. This gets you out of the hint-bit semantics and into a ton
of interesting problems, such as race conditions. (Process A determines
that tuple X is visible-to-all, and goes to update the index tuple.
Before it can reacquire lock on the index page, process B updates the
heap tuple and visits the index to clear the flag bit. Once A obtains
lock it will set the flag bit. Oops.)
Basically what you are buying into with such a thing is multiple copies
of critical state. It may be only one bit rather than several words,
but updating it is no less painful than if it were a full copy of the
tuple's commit status.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Cramer | 2004-05-01 18:50:47 | Re: Wierd context-switching issue on Xeon |
Previous Message | Gary Doades | 2004-05-01 12:48:35 | Re: planner/optimizer question |