On 25.12.2019 14:27, Marco Slot wrote:
On Wed, Dec 25, 2019, 11:28 Maksim Milyutin <milyuti...@gmail.com
<mailto:milyuti...@gmail.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