Re: Disallow cancellation of waiting for synchronous replication
От | Maksim Milyutin |
---|---|
Тема | Re: Disallow cancellation of waiting for synchronous replication |
Дата | |
Msg-id | 4e3cac62-1f04-13fa-90c2-3bc071ac9ccb@gmail.com обсуждение исходный текст |
Ответ на | Re: Disallow cancellation of waiting for synchronous replication (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Disallow cancellation of waiting for synchronous replication
|
Список | pgsql-hackers |
On 29.12.2019 00:55, Robert Haas wrote: > On Fri, Dec 20, 2019 at 12:04 AM Andrey Borodin <x4mmm@yandex-team.ru> wrote: >> Currently, we can have split brain with the combination of following steps: >> 0. Setup cluster with synchronous replication. Isolate primary from standbys. >> 1. Issue upsert query INSERT .. ON CONFLICT DO NOTHING >> 2. CANCEL 1 during wait for synchronous replication >> 3. Retry 1. Idempotent query will succeed and client have confirmation of written data, while it is not present on anystandby. > All that being said, like Tom and Michael, I don't think teaching the > backend to ignore cancels is the right approach. We have had > innumerable problems over the years that were caused by the backend > failing to respond to cancels when we would really have liked it to do > so, and users REALLY hate it when you tell them that they have to shut > down and restart (with crash recovery) the entire database because of > a single stuck backend. > The stuckness of backend is not deadlock here. To cancel waiting of backend fluently, client is enough to turn off synchronous replication (change synchronous_standby_names through server reload) or change synchronous replica to another livable one (again through changing of synchronous_standby_names). In first case he explicitly agrees with existence of local (not replicated) commits in master. -- Best regards, Maksim Milyutin
В списке pgsql-hackers по дате отправления: