On Wed, Jun 8, 2011 at 4:59 AM, Dan Ports <drkp@csail.mit.edu> wrote:
> 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).
I'm wondering if this shouldn't be linked to whether the scan is using
an MVCC snapshot, rather than inserting exceptions for specific
operations.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
