Robert Haas <robertmhaas@gmail.com> writes:
> 1. If a die interrupt is received (pg_terminate_backend or fast
> shutdown), then terminate the sync rep wait and arrange for the
> connection to be closed without acknowledging the commit (but do send
> a warning message back). The commit still happened, though, so other
> transactions will see its effects. This is unavoidable unless we're
> willing to either ignore attempts to terminate a backend waiting for
> sync rep, or panic the system when it happens, and I don't think
> either of those is appropriate.
Is it possible to force the standby out here, so that logs show that
there was something going on wrt replication?
> 2. If a query cancel interrupt is received (pg_cancel_backend or ^C),
> then cancel the sync rep wait and issue a warning before acknowledging
> the commit. Again, the alternative is to either ignore the cancel or
> panic, neither of which I believe to be what users will want.
Or force the standby to disconnect.
In both those cases what we have is a situation were either we can't
satisfy the user request or we can't continue to offer sync rep. You're
saying that we have to satisfy the user's query, so I say kick off sync
rep or it does not make any sense.
> 3. If synchronous_standby_names is changed to '' by editing
> postgresql.conf and issuing pg_ctl reload, then cancel all waits in
> progress and wake everybody up. As I mentioned before, reloading the
Ok.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
