Re: [HACKERS] crash-safe visibility map, take four

On 31.03.2011 11:33, 高增琦 wrote: Consider a example: 1. delete on two pages, emits two log (1, page1, vm_clear_1), (2, page2, vm_clear_2) 2. "vm_clear_1" and "vm_clear_2" on same vm page 3. checkpoint, and vm page get torned, vm_clear_2 was lost 4. delete another page, emits one log (3, page1, vm_

Re: [HACKERS] crash-safe visibility map, take four

2011/3/30 Robert Haas > Maybe we could check PD_ALL_VISIBLE before > taking the buffer lock - if it appears to be set, then we pin the > visibility map page before taking the buffer lock. Otherwise, we take > the buffer lock at once. Either way, once we have the lock, we > recheck the bit. Onl

Re: [HACKERS] crash-safe visibility map, take four

On Wed, Mar 30, 2011 at 8:52 PM, Heikki Linnakangas < heikki.linnakan...@enterprisedb.com> wrote: > On 30.03.2011 06:24, 高增琦 wrote: > >> 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 in

Re: [HACKERS] crash-safe visibility map, take four

On Wed, Mar 30, 2011 at 8:52 AM, Heikki Linnakangas wrote: > Yeah, that's a straightforward way to fix it. I don't think the performance > hit will be too bad. But we need to be careful not to hold locks while doing > I/O, which might require some rearrangement of the code. We might want to do > a

Re: [HACKERS] crash-safe visibility map, take four

On 30.03.2011 06:24, 高增琦 wrote: 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,

Re: [HACKERS] 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

Re: [HACKERS] crash-safe visibility map, take four

On Wed, Mar 23, 2011 at 6:16 AM, Jesper Krogh 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 complica

Re: [HACKERS] crash-safe visibility map, take four

On Thu, Mar 24, 2011 at 12:56 AM, Gokulakannan Somasundaram wrote: > Yeah. i looked at it. I don't think it addresses the problem raised here. > http://archives.postgresql.org/pgsql-hackers/2010-02/msg02097.php > Or may be i am missing something. Yeah, I think you're right. -- Robert Haas Enter

Re: [HACKERS] crash-safe visibility map, take four

Yeah. i looked at it. I don't think it addresses the problem raised here. http://archives.postgresql.org/pgsql-hackers/2010-02/msg02097.php Or may be i am missing something. Thanks. On Wed, Mar 23, 2011 at 7:54 PM, Robert Haas

Re: [HACKERS] crash-safe visibility map, take four

On Wed, Mar 23, 2011 at 1:16 AM, Jesper Krogh 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 complica

Re: [HACKERS] crash-safe visibility map, take four

On Wed, Mar 23, 2011 at 2:16 AM, Jesper Krogh 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 complica

Re: [HACKERS] crash-safe visibility map, take four

On Wed, Mar 23, 2011 at 2:29 AM, Gokulakannan Somasundaram wrote: >> All operations that clear the bit area are already WAL-logged. >> > Is it the case with visibility map also? > Thanks. Yes. Look at the comment that the patch removes. That describes the problem being fixed. -- Robert Haas E

Re: [HACKERS] crash-safe visibility map, take four

> > > All operations that clear the bit area are already WAL-logged. > > Is it the case with visibility map also? Thanks.

Re: [HACKERS] crash-safe visibility map, take four

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 th

Re: [HACKERS] crash-safe visibility map, take four

On Tue, Mar 22, 2011 at 11:59 PM, Gokulakannan Somasundaram 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

Re: [HACKERS] crash-safe visibility map, take four

> > 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

[HACKERS] crash-safe visibility map, take four

On Wed, Dec 1, 2010 at 11:25 AM, Robert Haas wrote: > As far as I can tell, there are basically two viable solutions on the > table here. > > 1. Every time we observe a page as all-visible, (a) set the > PD_ALL_VISIBLE bit on the page, without bumping the LSN; (b) set the > bit in the visibility m