Re: crash-safe visibility map, take four

Hi,

Should we do full-page write for visibilitymap all the time?
Now, when clear visiblitymap, there is no full-page write for vm
since we don't save buffer info in insert/update/delete's log.

The full-page write is used to protect pages from disk failure. Without it,
1) set vm: the vm bits that should be set to 1 may still be 0
2) clear vm: the vm bits that should be set to 0 may still be 1
Are these true? Or the page is totally unpredictable?

Another question:
To address the problem in
http://archives.postgresql.org/pgsql-hackers/2010-02/msg02097.php
, should we just clear the vm before the log of insert/update/delete?
This may reduce the performance, is there another solution?

Thanks.

--
GaoZengqi
pgf00a(at)gmail(dot)com
zengqigao(at)gmail(dot)com

On Fri, Mar 25, 2011 at 6:05 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:

> On Wed, Mar 23, 2011 at 6:16 AM, Jesper Krogh <jesper(at)krogh(dot)cc> wrote:
> > On 2011-03-22 21:43, Robert Haas wrote:
> >>
> >> I took a crack at implementing the first approach described above,
> >> which seems to be by far the simplest idea we've come up with to date.
> >> Patch attached. It doesn't seem to be that complicated, which could
> >> mean either that it's not that complicated or that I'm missing
> >> something. Feel free to point and snicker in the latter case.
> >
> > Looks simple, but there is now benefit...
>
> Your tests and discussion remind me that I haven't yet seen any tests
> that show that index-only scans would be useful for performance.
>
> Everyone just seems to be assuming that they make a huge difference,
> and that the difference is practically realisable in a common
> workload.
>
> Perhaps that's already been done and I just didn't notice?
>
> --
> Simon Riggs http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Training & Services
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>