I have a question about hot_standby_feedback parameter. In my understanding, if this parameter is on, a long running transaction on standby will not be canceled even if the transaction conflicts. So I have primary PostgreSQL and standby PostgreSQL running 9.2.4. On primary: create table t1(i int); insert into t1 values(1),(2),(3); On standby: begin; select * from t1; i --- 1 2 3 (3 rows) On primary: delete from t1; On standby: select * from t1; i --- (0 rows) On primary: vacuum verbose t1; INFO: vacuuming "public.t1" INFO: "t1": removed 3 row versions in 1 pages INFO: "t1": found 3 removable, 0 nonremovable row versions in 1 out of 1 pages DETAIL: 0 dead row versions cannot be removed yet. There were 0 unused item pointers. 0 pages are entirely empty. CPU 0.00s/0.00u sec elapsed 0.00 sec. INFO: "t1": truncated 1 to 0 pages DETAIL: CPU 0.00s/0.00u sec elapsed 0.00 sec. VACUUM As you can see vacuum on the primary removes all the rows in t1. I thought vacuum will not make the page entriely empty because of the effect of hot_standby_feedback. After while, on standby: test=# select * from t1; FATAL: terminating connection due to conflict with recovery DETAIL: User was holding a relation lock for too long. HINT: In a moment you should be able to reconnect to the database and repeat your command. Again, this is not what I expected. Am I missing something? -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese: http://www.sraoss.co.jp -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
