Re: BUG: Former primary node might stuck when started as a standby
| От | Michael Paquier |
|---|---|
| Тема | Re: BUG: Former primary node might stuck when started as a standby |
| Дата | |
| Msg-id | aaZ77VvZ4Oabp30A@paquier.xyz обсуждение |
| Ответ на | RE: BUG: Former primary node might stuck when started as a standby ("Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>) |
| Ответы |
Re: BUG: Former primary node might stuck when started as a standby
RE: BUG: Former primary node might stuck when started as a standby |
| Список | pgsql-hackers |
On Tue, Mar 03, 2026 at 04:02:53AM +0000, Hayato Kuroda (Fujitsu) wrote: > I had a concern that some BF animals have not enable the injection point yet > thus coverage might be decreased for them. But it's OK for me to fix > it. Requiring injection points to be enabled so as we have a strict control over the standby snapshot records does not strike me as a bad requirement in itself. Most of the animals use the switch these days. It's a bit sad if this is not entirely stable in pre-v16 branches, but a stable post-v17 behavior would always be better than an unstable behavior everywhere. > I preferred to add descriptions at the place checking enable_injection_points. > See the updated version. + autovacuum = off + checkpoint_timeout = 1h Why do we need these? An explanation seems in order in the shape of a commit, or these should be removed. Is there a different trick than the one posted at [1] to check the stability of the proposal? I am wondering if I am missing something, or if that's all. Alexander? [1]: https://www.postgresql.org/message-id/e1cf52d2-c344-4dfd-a918-e5f20ff04fa2@gmail.com -- Michael
Вложения
В списке pgsql-hackers по дате отправления: