On Thu, Nov 1, 2012 at 1:48 PM, David Fetter
<david@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