Re: crash-safe visibility map, take five - Mailing list pgsql-hackers

From Tom Lane
Subject Re: crash-safe visibility map, take five
Date
Msg-id 18437.1305046811@sss.pgh.pa.us
Whole thread Raw
In response to Re: crash-safe visibility map, take five  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: crash-safe visibility map, take five  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, May 10, 2011 at 11:34 AM, Jesper Krogh <jesper@krogh.cc> wrote:
>> Or what is the downside for keeping it across IO? Will it block other
>> processes trying to read it?

> Heikki might be in a better position to comment on that than I am,
> since he wrote the existing code.  But I think that's basically the
> issue.  When one process has an exclusive buffer lock, nobody else can
> scan the tuples in that block - so a sequential scan, for example,
> that reached that block, or an index scan that needed to probe into
> it, would pile up behind the read of the visibility map page.

Right, it's the loss of potential concurrency that's annoying here.

On the other hand, the concurrency loss might be entirely theoretical
--- in particular, if other potential readers of the heap page would
probably also need to wait for the visibility page to come in, then
nothing is gained by letting them acquire the heap page lock sooner.

I've not read this thread in any detail yet, but if we're going to be
jumping through extremely complex hoops to avoid that scenario, it might
be better to KISS ... especially in the first iteration.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: hint bit cache v5
Next
From: Robert Haas
Date:
Subject: Re: collateral benefits of a crash-safe visibility map