Re: Tricky bugs in concurrent index build
| От | Gregory Stark |
|---|---|
| Тема | Re: Tricky bugs in concurrent index build |
| Дата | |
| Msg-id | 87odu9w5fz.fsf@enterprisedb.com обсуждение исходный текст |
| Ответ на | Re: Tricky bugs in concurrent index build (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: Tricky bugs in concurrent index build
|
| Список | pgsql-hackers |
Tom Lane <tgl@sss.pgh.pa.us> writes: > At the moment it may be moot, because I've realized that validate_index > doesn't work anyway. It is scanning the index and then assuming that > any tuple inserted into the index subsequent to that scan will still be > INSERT_IN_PROGRESS when the heapscan reaches it. EGADS Boy I feel stupid now. In fairness I think what happened is that the original plan was, like your new plan, based on snapshots. And I only switched to using HeapSatisfiesVacuum after several iterations. I guess there were some assumptions in the original thinking that I never revisited. Because of the way the AM API works changing how the initial heap scan works is a bit of a pain. It would require either having some global state or passing the concurrent flag through the AM methods or alternatively having a whole new AM method. I'll have to read (and reread) your description again in the morning -- Gregory Stark EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: