Bug in visibility hint bit
От | Jeff Janes |
---|---|
Тема | Bug in visibility hint bit |
Дата | |
Msg-id | f67928030908241823q417ea005sd03b2d888ea84ad@mail.gmail.com обсуждение исходный текст |
Ответы |
Re: Bug in visibility hint bit
Re: Bug in visibility hint bit |
Список | pgsql-hackers |
There seems to be a bug in the visibility map in 8.4.0, introduced to cvs on 2008-12-03. It results in tuples being called visible that shouldn't be. In heap_update function from heapam.c: /* * Note: we mustn't clear PD_ALL_VISIBLE flags before writing the WAL * record, because log_heap_updatelooks at those flags to set the * corresponding flags in the WAL record. */ So the full_page_write of the block sent to WAL has the wrong PD_ALL_VISIBLE. It needs to be fixed during WAL replay after a crash.But it is not. In heap_xlog_update: if (record->xl_info & XLR_BKP_BLOCK_1) { if (samepage) return; /* backup block covered both changes */ goto newt; } The goto newt causes it to skip the code that would have called PageClearAllVisible. I don't feel particularly competent to propose a patch for this. It seems to me that log_heap_update should be sent the correct block in the first place, and some other method should be used to communicate between heap_update and log_heap_update if communication is necessary. But really, I don't think such communication should be necessary, and the xlrec.all_visible_cleared and xlrec.new_all_visible_cleared fields are unneeded. Just assume they are true. It seems like the worst thing that can happen is that we call PageClearAllVisible when it is already cleared, which is hardly harmful (the blocks that have redo applied to them are already dirty, so a spurious clear doesn't cause unneeded IO) Jeff
В списке pgsql-hackers по дате отправления: