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