> 29 дек. 2019 г., в 4:54, Robert Haas <robertmhaas@gmail.com> написал(а):
>
> On Sat, Dec 28, 2019 at 6:19 PM Maksim Milyutin <milyutinma@gmail.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.
Not loosing data - is a nice property of the database either.
Currently, synchronous replication fails to provide its guaranty - no data will be acknowledged until it is replicated.
We want to create a mode where this guaranty is provided.
When user issued CANCEL we could return him his warning or error, but we should not drop data locks. Other transactions
shouldnot get acknowledged on basis of non-replicated data.
> 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.
There are many cases when we do not allow user to shoot into his foot. For example, anti-wraparound vacuum. Single-user
vacuumfreeze is much less pain than split-brain. In case of wraparound protection, there is deterministic steps to take
toget your database back consistently. But in case of split-brain there is no single plan for cure.
Best regards, Andrey Borodin.
