Re: Bugs in CREATE/DROP INDEX CONCURRENTLY
| От | Kevin Grittner |
|---|---|
| Тема | Re: Bugs in CREATE/DROP INDEX CONCURRENTLY |
| Дата | |
| Msg-id | 20121018041203.155630@gmx.com обсуждение исходный текст |
| Ответ на | Bugs in CREATE/DROP INDEX CONCURRENTLY (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: Bugs in CREATE/DROP INDEX CONCURRENTLY
|
| Список | pgsql-hackers |
Kevin Grittner wrote: > Hmm. The comment is probably better now, but I've been re-checking > the code, and I think my actual code change is completely wrong. > Give me a bit to sort this out. I'm having trouble seeing a way to make this work without rearranging the code for concurrent drop to get to a state where it has set indisvalid = false, made that visible to all processes, and ensured that all scans of the index are complete -- while indisready is still true. That is the point where TransferPredicateLocksToHeapRelation() could be safely called. Then we would need to set indisready = false, make that visible to all processes, and ensure that all access to the index is complete. I can't see where it works to set both flags at the same time. I want to sleep on it to see if I can come up with any other way, but right now that's the only way I'm seeing to make DROP INDEX CONCURRENTLY compatible with SERIALIZABLE transactions. :-( -Kevin
В списке pgsql-hackers по дате отправления: