On 03/26/2015 08:00 PM, Peter Geoghegan wrote:
> On Wed, Mar 25, 2015 at 12:42 PM, Peter Geoghegan <pg@heroku.com> wrote:
>> My next revision will have a more polished version of this scheme. I'm
>> not going to immediately act on Robert's feedback elsewhere (although
>> I'd like to), owing to time constraints - no reason to deny you the
>> opportunity to review the entirely unrelated low-level speculative
>> locking mechanism due to that.
>
> Attached revision, V3.1, implements this slightly different way of
> figuring out if an insertion is speculative, as discussed. We reuse
> t_ctid for speculatively inserted tuples. That's where the counter
> goes. I think that this is a significant improvement, since there is
> no longer any need to touch the proc array for any reason, without
> there being any significant disadvantage that I'm aware of. I also
> fixed some bitrot, and a bug with index costing (the details aren't
> terribly interesting - tuple width wasn't being calculated correctly).
Cool. Quickly looking at the patch though - does it actually work as it
is? RelationPutHeapTuple will overwrite the ctid field when the tuple is
put on the page, so I don't think the correct token will make it to disk
as the patch stands. Also, there are a few places where we currently
check if t_ctid equals the tuple's location, and try to follow t_ctid if
it doesn't. I think those need to be taught that t_ctid can also be a token.
- Heikki