Bill Studenmund <[EMAIL PROTECTED]> writes:
> One problem though is that if you don't have a spin lock around the flag,
> you can end up clearing it inadvertenty. i.e. two backends go to update
> (different) bit flags. They each load the current value, and each set the
> (different) bit they want
Sorry for the delay.
On Tue, 3 Jul 2001, Tom Lane wrote:
> [EMAIL PROTECTED] (Nathan Myers) writes:
>
> > Also, as hints, would it be Bad(tm) if an attempt to clear one failed?
>
> Clearing hint bits is also an exclusive-lock-only operation. Notice
> I specified that *setting* them is the onl
[EMAIL PROTECTED] (Nathan Myers) writes:
> Here, backend B is a good citizen and locks while it makes its change.
No, backend B wasn't a good citizen: it should have been holding
exclusive lock on the buffer.
> Also, as hints, would it be Bad(tm) if an attempt to clear one failed?
Clearing hint
[EMAIL PROTECTED] (Nathan Myers) writes:
> On Mon, Jul 02, 2001 at 09:40:25PM -0400, Tom Lane wrote:
>> 4. It is considered OK to update tuple commit status bits (ie, OR the
>> values HEAP_XMIN_COMMITTED, HEAP_XMIN_INVALID, HEAP_XMAX_COMMITTED, or
>> HEAP_XMAX_INVALID into t_infomask) while holdin
