Re: Disallow cancellation of waiting for synchronous replication

On 25.12.2019 14:27, Marco Slot wrote:

>
>
> On Wed, Dec 25, 2019, 11:28 Maksim Milyutin <milyutinma(at)gmail(dot)com
> <mailto:milyutinma(at)gmail(dot)com>> wrote:
>
> But in this case locally committed data becomes visible to new
> incoming
> transactions that is bad side-effect of this issue.
>
>
> Your application should be prepared for that in any case.
>
> At the point where synchronous replication waits, the commit has
> already been written to disk on the primary. If postgres
> restarts while waiting for replication then the write becomes
> immediately visible regardless of whether it was replicated.

Yes, this write is recovered after starting of instance. At first, this
case I want to delegate to external HA tool around PostgreSQL. It can
handle instance stopping and take switchover to sync replica or start
current instance with closed connections from external users until all
writes replicate to sync replicas. Later, arguably closing connection
after recovery process could be implemented inside the kernel.

> I don't think throwing a PANIC actually prevents that and if it does
> it's coincidental.

PANIC lets down instance and doesn't provide clients to read locally
committed data. HA tool takes further steps to close access to these
data as described above.

> That's far from ideal, but fixing it requires a much bigger change to
> streaming replication. The write should be replicated prior to commit
> on the primary, but applied after in a way where unapplied writes on
> the secondary can be overwritten/discarded if it turns out they did
> not commit on the primary.

Thanks for sharing your opinion about enhancement of synchronous commit
protocol. Here [1] my position is listed. It would like to see positions
of other members of community.

1.
https://www.postgresql.org/message-id/f3ffc220-e601-cc43-3784-f9bba66dc382%40gmail.com

--
Best regards,
Maksim Milyutin