Re: Eliminating PD_ALL_VISIBLE, take 2

On Mon, Jul 1, 2013 at 1:21 PM, Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
> On Sun, 2013-06-30 at 22:58 -0400, Robert Haas wrote:
>> I thought that Jeff withdrew this patch.
>
> No -- was there a reason you thought that?

I thought I remembered you saying you were going to abandon it in the
face of objections.

> I know it could use another
> round of testing before commit, and there may be a couple other things
> to clear up. But I don't want to invest a lot of time there right now,
> because, as I understand it, you still object to the patch anyway.
>
> I am still not entirely clear on the objections to this patch:
>
> 1. Contention was a concern, but I believe I have mitigated it. Strictly
> speaking, additional pins may be acquired, but the cost of those pin
> operations will be spread over a lot of other work.
>
> 2. There are quite a few different ideas about where we're going with
> PD_ALL_VISIBLE and freezing, but it seems like removing PD_ALL_VISIBLE
> is potentially compatible with most of them.
>
> Any others?
>
> The patch reduces code complexity and reduces writes during a data load.

Well, I don't believe there's any way to really eliminate the
contention concern completely. There's no way around the fact that it
means more access to the visibility map, and I've seen recent (albeit
circumstantial thus far) evidence that that can be a real problem.
The buffer mapping locks are a problem, too, so anything that means
more page accesses can't be taken lightly. I agree your proposed
changes reduce the chances of problems; I don't agree that they
eliminate them.

The other concern I remember being expressed (and not just by me, but
by a number of people) is that your patch turns loss of a visibility
map bit into a data corruption scenario, which it currently isn't.
Right now, if your visibility map gets corrupted, you can always
recover by deleting it. Under your proposal that would no longer be
possible. I think that's sufficient grounds to reject the patch by
itself, even if there were no other issues. If that doesn't strike
you as very dangerous, I'm baffled as to why not.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company