Re: BUG #17401: REINDEX TABLE CONCURRENTLY creates a race condition on a streaming replica
От | Michael Paquier |
---|---|
Тема | Re: BUG #17401: REINDEX TABLE CONCURRENTLY creates a race condition on a streaming replica |
Дата | |
Msg-id | YmYtfjtKnV/v3lXn@paquier.xyz обсуждение исходный текст |
Ответ на | Re: BUG #17401: REINDEX TABLE CONCURRENTLY creates a race condition on a streaming replica (Noah Misch <noah@leadboat.com>) |
Ответы |
Re: BUG #17401: REINDEX TABLE CONCURRENTLY creates a race condition on a streaming replica
|
Список | pgsql-bugs |
On Sat, Apr 23, 2022 at 08:03:47PM -0700, Noah Misch wrote: > If this thread proceeds with the current LogAccessExclusiveLock() design, I > think it must include a way to disable the new behavior. That requirement > would apply to any design that delays standby WAL apply in a way that > hot_standby_feedback can't mitigate. We have the vacuum_truncate reloption > because AEL is disruptive to standby freshness. Adding a new kind of > unavoidable AEL would be similarly-painful. I am not sure that we should add more reloptions that bypass AEL requirements FWIW, because the standby would still be opened to cache errors if you don't log something, would it not?. I agree that vacuum_truncate is handy, but there was a lot of drawback with it as well when it was introduced as there were arguments that we'd better remove the use of the AEL used for the end-of-vacuum truncation. > It would nicer to fix this such that, with hot_standby_feedback, the fix > delays CIC on the primary instead of delaying apply on the standby. If that's > too hard, AEL plus option-to-disable sounds fine. Perhaps. Still, that would be mostly what WaitForOlderSnapshots() already does, except that we'd roughly just use the limitXmin from the snapshot of the transaction currently running? -- Michael
Вложения
В списке pgsql-bugs по дате отправления: