Re: BUG #17568: unexpected zero page at block 0 during REINDEX CONCURRENTLY
От | Tom Lane |
---|---|
Тема | Re: BUG #17568: unexpected zero page at block 0 during REINDEX CONCURRENTLY |
Дата | |
Msg-id | 996031.1660607800@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #17568: unexpected zero page at block 0 during REINDEX CONCURRENTLY (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: BUG #17568: unexpected zero page at block 0 during REINDEX CONCURRENTLY
|
Список | pgsql-bugs |
Andres Freund <andres@anarazel.de> writes: > The easiest fix is likely to force all buffers to be forgotten at the end of > index_concurrently_build() or such. Race conditions there ... > I don't immediately see a nicer way to fix > this, we can't just lock the new index relation exclusively. Why not? If the index isn't valid yet, other backends have zero business touching it. I'd think about taking an exclusive lock to start with, and releasing it (downgrading to a non-exclusive lock) once the index is valid enough that other backends can access it, which would be just before we set pg_index.indisready to true. Basically, this is to enforce the previously-implicit contract that other sessions won't touch the index too soon against careless superusers. regards, tom lane
В списке pgsql-bugs по дате отправления: