From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: SSI patch version 14 |
Date: | 2011-01-31 21:13:00 |
Message-ID: | 1296508380.7673.24.camel@jdavis-ux.asterdata.local |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, 2011-01-31 at 14:38 -0600, Kevin Grittner wrote:
> It is at least as likely that I'm missing something. If I'm
> following you, we're talking about these 24 lines of code, where
> "valid" is the what was just returned from
> HeapTupleSatisfiesVisibility:
Yes.
> (1) Do you see a case where this would do the wrong thing? Can you
> describe that or (even better) provide a test case to demonstrate
> it?
No, I don't see any incorrect results.
> (2) I haven't gotten my head around how HTSV helps or is even the
> right thing.
It primarily just encapsulates the access to the tuple header fields. I
think that avoiding the messy logic of hint bits, tuple locks, etc., is
a significant win for readability and maintainability.
> If I want to try the switch statement from your recent
> post, what should I use as the OldestXmin value on the call to HTSV?
I believe RecentGlobalXmin should work.
And I don't think the original switch statement I posted did the right
thing for HEAPTUPLE_LIVE. I think that case needs to account for the
visible flag (if it's live but not visible, that's the same as
insert-in-progress for your purposes).
Regards,
Jeff Davis
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2011-01-31 21:20:43 | Re: SSI patch version 14 |
Previous Message | Greg Smith | 2011-01-31 21:04:13 | Re: Spread checkpoint sync |