Tom Lane wrote:
> Kevin Brown <[EMAIL PROTECTED]> writes:
> > In the above for large relations, the bulk of the REINDEX should
> > happen without any locks being held by the REINDEX operation.
>
> As I just pointed out to Greg, the arm-waving notion that you can "turn
> off the FSM" requires a great deal of low-level locking that is not
> there now.
Yeah, I thought that the check for use of the FSM was already being
done by the lower level operators, and that contention would only
occur on the modification of the FSM "enabled" flag. Obviously this
doesn't work at all if the FSM is just assumed to be in use at all
times, or if the FSM values are read only at transaction start or
something...
> Even ignoring that, you *still* have a lock upgrade problem
> in this sketch.
Hmm, well, I can see a deadlock potential for those operations that
have to acquire multiple locks simultaneously, and I suppose that the
table + FSM lock would qualify in the sequence here, but the rest of
it involves just a single read lock against the table. What am I
missing?
--
Kevin Brown [EMAIL PROTECTED]
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
