Re: Disallow cancellation of waiting for synchronous replication

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Maksim Milyutin <milyutinma(at)gmail(dot)com>
Cc: Andrey Borodin <x4mmm(at)yandex-team(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Disallow cancellation of waiting for synchronous replication
Date: 2019-12-28 23:54:03
Message-ID: CA+TgmoaCBwgMDkeBDOgtPgHcbfSYq+zORjL5DoU3pJyjALxtoQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Dec 28, 2019 at 6:19 PM Maksim Milyutin <milyutinma(at)gmail(dot)com> wrote:
> 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.

Sure, that's true. But I still maintain that responding to ^C is an
important property of the system. If you have to do some more
complicated set of steps like the ones you propose here, a decent
number of people aren't going to figure it out and will end up
unhappy. Now, as it is, you're unhappy, so I guess you can't please
everyone, but you asked for opinions so I'm giving you mine.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2019-12-28 23:56:41 Re: Building infrastructure for B-Tree deduplication that recognizes when opclass equality is also equivalence
Previous Message Tomas Vondra 2019-12-28 23:34:33 Re: xact_start for walsender & logical decoding not updated