Re: Freezing without write I/O

On Wed, 2013-09-25 at 12:31 +0300, Heikki Linnakangas wrote:
> On 19.09.2013 16:24, Andres Freund wrote:
> ...
> > There's probably more.

I think _bt_check_unique is also a problem.

> Hmm, some of those are trivial, but others, rewrite_heap_tuple() are
> currently only passed the HeapTuple, with no reference to the page where
> the tuple came from. Instead of changing code to always pass that along
> with a tuple, I think we should add a boolean to HeapTupleData, to
> indicate if the tuple came from a mature page. If the flag is set, the
> tuple should be considered visible to everyone, without looking at the
> xmin/xmax. This might affect extensions, although usually external C
> code that have to deal with HeapTuples will use functions like
> heap_form_tuple to do so, and won't need to deal with low-level stuff or
> visibility themselves.

How bad would the code be to just pass along the buffer when it's
needed? After looking around, it doesn't seem necessarily worse than
adding the struct field (and I agree with Andres that it seems more
proper to pass the buffer along).

I also have a separate question about this patch:

It seems like this gets us closer to 64-bit transaction IDs. Can we get
some help from the compiler to distinguish the two cases in a less
error-prone way? Is it worth thinking about making 64-bit the norm, and
32-bit an optimization in certain places (e.g. the heap and maybe the
xip array of a snapshot)?

Regards,
Jeff Davis