Re: BUG #17401: REINDEX TABLE CONCURRENTLY creates a race condition on a streaming replica
От | Andrey Borodin |
---|---|
Тема | Re: BUG #17401: REINDEX TABLE CONCURRENTLY creates a race condition on a streaming replica |
Дата | |
Msg-id | 04D2D137-102E-400D-B66B-C073C27A1327@yandex-team.ru обсуждение исходный текст |
Ответ на | Re: BUG #17401: REINDEX TABLE CONCURRENTLY creates a race condition on a streaming replica (Ben Chobot <bench@silentmedia.com>) |
Ответы |
Re: BUG #17401: REINDEX TABLE CONCURRENTLY creates a race condition on a streaming replica
|
Список | pgsql-bugs |
> On 10 Feb 2022, at 22:18, Ben Chobot <bench@silentmedia.com> wrote: > > Andrey Borodin wrote on 2/10/22 8:52 AM: >> I think it’s somewhat unexpected. But is it a real problem? > > If you're asking me, then I can't speak to your standby log, but I'd say the bug I raised is a problem, yes. :) Well, not exactly. I had attached the patch with the test that reproduces some problem with dropped index on standby. In this test we have a standby and check query on it at some point finds out that it’s working with invalid index. I’m notsure that this is reproduction of your exact problem. I see that we are swapping indexes on primary in a following way: index_concurrently_swap(newidx->indexId, oldidx->indexId, oldName); // WAL-logged CacheInvalidateRelcacheByRelid(oldidx->tableId); // Not WAL-logged CommitTransactionCommand(); // WAL-logged But I do not know is it expected to work on standby, since relcache invalidation is not logged. Maybe Peter or someone moreexperienced than me can explain how this is expected to work. Thanks! Best regards, Andrey Borodin.
В списке pgsql-bugs по дате отправления: