On Wed, Feb 1, 2012 at 8:01 PM, Alvaro Herrera alvhe...@alvh.no-ip.org wrote:
Suggested patch attached. I'd backpatch this as far as it applies
cleanly.
This is new code in 9.2, but it's modelled on heap_freeze_tuple(), which is old.
I'm not convinced that it's a bug. Suppose that xmax is
Robert Haas robertmh...@gmail.com writes:
I'm not convinced that it's a bug. Suppose that xmax is set but is
hinted as invalid.
XMAX_INVALID is not a hint. When it's set, the contents of the field
must be presumed to be garbage. Any code failing to adhere to that rule
is broken.
We process
On Thu, Feb 2, 2012 at 11:27 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I'm not convinced that it's a bug. Suppose that xmax is set but is
hinted as invalid.
XMAX_INVALID is not a hint. When it's set, the contents of the field
must be presumed to be
On Thu, Feb 2, 2012 at 12:45 PM, Robert Haas robertmh...@gmail.com wrote:
I believe the adequate defense that we have is precisely the logic you
are proposing to change. Regardless of whether you want to call
XMAX_INVALID a hint or, say, a giant tortoise, I am fairly sure that
we don't
Hi,
I noticed that heap_tuple_needs_freeze might return true in cases where
the Xmax is leftover junk from somebody who set HEAP_XMAX_INVALID in the
far past without resetting the Xmax value itself to Invalid. I think
this is incorrect usage; the rule, I think, is that one shouldn't even
read
Alvaro Herrera alvhe...@alvh.no-ip.org writes:
! if (!(tuple-t_infomask HEAP_XMAX_INVALID))
{
! if (!(tuple-t_infomask HEAP_XMAX_IS_MULTI))
How about just one test,
if (!(tuple-t_infomask (HEAP_XMAX_INVALID | HEAP_XMAX_IS_MULTI)))
But other than that quibble,
