Re: Reviewing freeze map code - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Reviewing freeze map code
Date
Msg-id 20160701192351.s6revshsn2ir4szq@alap3.anarazel.de
Whole thread Raw
In response to Re: Reviewing freeze map code  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Reviewing freeze map code  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Re: Reviewing freeze map code  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
On 2016-07-01 15:18:39 -0400, Robert Haas wrote:
> On Fri, Jul 1, 2016 at 10:22 AM, Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> > Ah, you're right, I misunderstood.
> >
> > Attached updated patch incorporating your comments.
> > I've changed it so that heap_xlog_lock clears vm flags if page is
> > marked all frozen.
> 
> I believe that this should be separated into two patches, since there
> are two issues here:
> 
> 1. Locking a tuple doesn't clear the all-frozen bit, but needs to do so.
> 2. heap_update releases the buffer content lock without logging the
> changes it has made.
> 
> With respect to #1, there is no need to clear the all-visible bit,
> only the all-frozen bit.  However, that's a bit tricky given that we
> removed PD_ALL_FROZEN.  Should we think about putting that back again?

I think it's fine to just do the vm lookup.

> Should we just clear all-visible and call it good enough?

Given that we need to do that in heap_lock_tuple, which entirely
preserves all-visible (but shouldn't preserve all-frozen), ISTM we
better find something that doesn't invalidate all-visible.


> The only
> cost of that is that vacuum will come along and mark the page
> all-visible again instead of skipping it, but that's probably not an
> enormous expense in most cases.

I think the main cost is not having the page marked as all-visible for
index-only purposes. If it's an insert mostly table, it can be a long
while till vacuum comes around.

Andres



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Reviewing freeze map code
Next
From: Peter Geoghegan
Date:
Subject: Re: Bug in batch tuplesort memory CLUSTER case (9.6 only)