On Thu, Feb 2, 2012 at 12:45 PM, Robert Haas 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 WAL-log setting it. Tha
On Thu, Feb 2, 2012 at 11:27 AM, Tom Lane wrote:
> Robert Haas 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 ad
Robert Haas 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 the table and ad
On Wed, Feb 1, 2012 at 8:01 PM, Alvaro Herrera 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 set but is
hinted as inv
Alvaro Herrera 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, yeah, it's a b
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 Xma
