On Thu, Nov 1, 2012 at 1:48 PM, David Fetter <da...@fetter.org> wrote:
> I guess my disk subsystem (it's a consumer-grade DAS SSD) doesn't have > enough latency for my reflexes to hit ^C fast enough. Any way to > inject this fault deterministically? > If the point is to get this warning, you can always setup synchronous_standby_names with the application name of a slave that is not listed in pg_stat_replication to make the master hanging for a slave that does not exist :) But in this case there is virtually no slave to wait for, so perhaps it has no meaning... But it lets you all time you want to do a manual cancel and get this warning. For example: postgres=# show synchronous_standby_names; synchronous_standby_names --------------------------- slave2 (1 row) postgres=# select application_name, sync_state from pg_stat_replication; application_name | sync_state ------------------+------------ slave1 | async (1 row) postgres=# begin; BEGIN postgres=# create table aa (a int); CREATE TABLE postgres=# commit; ^CCancel request sent WARNING: canceling wait for synchronous replication due to user request DETAIL: The transaction has already committed locally, but might not have been replicated to the standby. COMMIT postgres=# show synchronous_commit; synchronous_commit -------------------- on (1 row) postgres=# \d List of relations Schema | Name | Type | Owner --------+------+-------+--------- public | aa | table | michael (1 row) Btw, I believe that this is correct behavior, because in Peter's case the manual command gets the priority on the value of synchronous_commit, no? If anybody thinks that I am wrong, feel free to argue on that of course... -- Michael Paquier http://michael.otacoo.com