concurrent index builds unneeded lock? - Mailing list pgsql-hackers
From | Theo Schlossnagle |
---|---|
Subject | concurrent index builds unneeded lock? |
Date | |
Msg-id | DC895D03-8812-4DA5-816E-E13E1F6D764A@omniti.com Whole thread Raw |
Responses |
Re: concurrent index builds unneeded lock?
|
List | pgsql-hackers |
We just ran into a case where we were performing two concurrent index builds on two different tables in two different schemas in the same database (no relational constraints between them). One of the index builds locked on the other. The first index build started... The second index build started... The first one locked on the second one.... The second one finished... The first one was allows to continue and finish. quux=# select * from pg_locks where pid IN (25264, 20108); locktype | database | relation | page | tuple | virtualxid| transactionid | classid | objid | objsubid | virtualtransaction | pid | mode | granted ------------+----------+----------+------+-------+------------ +---------------+---------+-------+----------+-------------------- +-------+--------------------------+--------- relation | 16385 | 25852 | | | | | | | | 9/3041 | 20108 | RowExclusiveLock | t relation | 16385 | 25861 | | | | | | | | 1/15735 | 25264 | RowExclusiveLock | t relation | 16385 | 16421 | | | | | | | | 9/3041 | 20108 | ShareUpdateExclusiveLock | t virtualxid | | | | | 9/3041 | | | | | 9/3041 | 20108 | ExclusiveLock | t virtualxid | | | | | 1/15735 | | | | | 1/15735 | 25264 | ExclusiveLock | t virtualxid | | | | | 9/3041 | | | | | 1/15735 | 25264 | ShareLock | f relation | 16385 | 16528 | | | | | | | | 1/15735 | 25264 | ShareUpdateExclusiveLock | t (7 rows) Reading the comments in the concurrent index build code, it seems that in prep for phase 3 of the index build it looks for any open txns that could feasibly see deleted tuples prior to the snap. I would think it would be txns that would be reading that table, but I'm thinking it is a bit to aggressive. Am I reading the code wrong there? I'm thinking it should be more selective about vxids it chooses to block on. I'd expect it to block on vxids touching the same table only. Thoughts? -- Theo Schlossnagle http://omniti.com/is/theo-schlossnagle p: +1.443.325.1357 x201 f: +1.410.872.4911
pgsql-hackers by date: