On Tue, Aug 6, 2019 at 9:26 PM Heikki Linnakangas <hlinn...@iki.fi> wrote: > I had some steam, and wrote a spec that reproduces this bug. It wasn't > actually that hard to reproduce, fortunately. Or unfortunately; people > might well be hitting it in production. I used the "freezetest.spec" > from the 2013 thread as the starting point, and added one UPDATE to the > initialization, so that the test starts with an already HOT-updated > tuple. It should throw a serialization error, but on current master, it > does not. After applying your fix.txt, it does.
Thanks! Ahh, right, I was expecting it to be harder to see an undetected anomaly, because of the index page lock, but of course we never actually write to that page so it's just the heap tuple lock holding everything together. > Your fix.txt seems correct. For clarity, I'd prefer moving things around > a bit, though, so that the t_self is set earlier in the function, at the > same place where the other HeapTuple fields are set. And set blkno and > offnum together, in one ItemPointerSet call. With that, I'm not sure we > need such a verbose comment explaining why t_self needs to be updated > but I kept it for now. +1 > Attached is a patch that contains your fix.txt with the changes for > clarity mentioned above, and an isolationtester test case. LGTM. > PS. Because heap_hot_search_buffer() now always sets heapTuple->t_self > to the returned tuple version, updating *tid is redundant. And the call > in heapam_index_fetch_tuple() wouldn't need to do > "bslot->base.tupdata.t_self = *tid". Right, that sounds like a separate improvement for master only. -- Thomas Munro https://enterprisedb.com
