Suspicious behaviour on applying XLOG_HEAP2_VISIBLE.
От | Masahiko Sawada |
---|---|
Тема | Suspicious behaviour on applying XLOG_HEAP2_VISIBLE. |
Дата | |
Msg-id | CAD21AoDpZ6Xjg=gFrGPnSn4oTRRcwK1EBrWCq9OqOHuAcMMC=w@mail.gmail.com обсуждение исходный текст |
Ответы |
Re: Suspicious behaviour on applying XLOG_HEAP2_VISIBLE.
|
Список | pgsql-hackers |
Hi all, I faced suspicious behaviour on hot standby server related to visibility map. The scenario is, 1. Create table and check internal of visibility map on master server. postgres(1)=# create table hoge (col int); CREATE TABLE postgres(1)=# insert into hoge select generate_series(1,10); INSERT 0 10 postgres(1)=# select * from pg_visibility('hoge'); blkno | all_visible | all_frozen | pd_all_visible -------+-------------+------------+---------------- 0 | f | f | f (1 row) 2. Check internal of visibility map on standby server. postgres(1)=# select * from pg_visibility('hoge'); blkno | all_visible | all_frozen | pd_all_visible -------+-------------+------------+---------------- 0 | f | f | f (1 row) 3. Do VACUUM on master server. postgres(1)=# vacuum hoge; VACUUM postgres(1)=# select * from pg_visibility('hoge'); blkno | all_visible | all_frozen | pd_all_visible -------+-------------+------------+---------------- 0 | t | f | t (1 row) 4. Check internal of visibility map on standby server again. ** Note that the we use the connection we established at #2 again ** postgres(1)=# select * from pg_visibility('hoge'); blkno | all_visible | all_frozen | pd_all_visible -------+-------------+------------+---------------- 0 | f | f | t (1 row) Even on standby server, the result should be (t,f,t), but returned (f,f,t) (XLOG_HEAP2_VISIBLE record actually has been reached to standby, and has been surely applied) As a result of looked into code around the recvoery, ISTM that the cause is related to relation cache clear. In heap_xlog_visible, if the standby server receives WAL record then relation cache is eventually cleared in vm_extend, but If standby server receives FPI then relation cache would not be cleared. For example, after I applied attached patch to HEAD, (it might not be right way but) this problem seems to be resolved. Is this a bug? or not? Regards, -- Masahiko Sawada
Вложения
В списке pgsql-hackers по дате отправления: