On 25.12.2019 14:27, Marco Slot 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