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
