From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Bug in visibility hint bit |
Date: | 2009-08-25 06:07:46 |
Message-ID: | 14815.1251180466@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Jeff Janes <jeff(dot)janes(at)gmail(dot)com> writes:
> ... 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)
Just to respond to that --- I spent awhile yesterday thinking the same
thing. But the value of those flags is to tell the WAL replay functions
whether they need to go and clear the corresponding bits in the
visibility map. Making them do that unconditionally for every
insert/update/delete would surely be a pretty big hit to the speed of
WAL replay, which already leaves a lot to be desired :-(
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Jean-Michel Pouré | 2009-08-25 06:49:59 | Re: DELETE syntax on JOINS |
Previous Message | Robert Haas | 2009-08-25 03:46:50 | Re: 8.5 release timetable, again |