Robert Haas <robertmh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
