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. I don't think throwing a PANIC actually prevents that and if it does it's coincidental. Best you can do is signal to the client that the commit status is unknown.
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.
Marco
