On Tue, Jun 07, 2011 at 10:14:30PM -0400, Tom Lane wrote:
> Do you mean page zero, as in the metapage (for most index types), or do
> you mean the root page? If the former, how is that not an outright bug,
> since it corresponds to no data? If the latter, how is that not a
> serious performance problem, since it corresponds to locking the entire
> index? Any way you slice it, it sounds like a pretty bad bug.
It's a moot point since that isn't actually happening, but FYI, we only
acquire and check for locks on b-tree leaf pages so locking the root
wouldn't have any effect. (This won't be true for other index types;
GIST comes to mind.)
> It's not apparent to me why an index build (regular or reindex) should
> create any predicate locks at all, ever. Surely it's a basically
> nontransactional operation that SSI should keep its fingers out of.
It shouldn't. What's happening is that when IndexBuildHeapScan reads
the heap tuples, heap_getnext takes a lock if it's running inside a
serializable transaction. It doesn't (yet) know that it doesn't need
the locks for an index build.
We could set a flag in the HeapScanDesc to indicate this. Actually,
setting rs_relpredicatelocked has exactly that effect, so we ought to
be able to use that (but might want to change the name).
Dan
--
Dan R. K. Ports MIT CSAIL http://drkp.net/