> 29 дек. 2019 г., в 4:54, Robert Haas <robertmh...@gmail.com> написал(а):
>
> On Sat, Dec 28, 2019 at 6:19 PM Maksim Milyutin <milyuti...@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 should not 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 vacuum freeze is much less pain
than split-brain. In case of wraparound protection, there is deterministic
steps to take to get your database back consistently. But in case of
split-brain there is no single plan for cure.
Best regards, Andrey Borodin.
