On Wed, Oct 4, 2017 at 11:00 AM, Wood, Dan <hexp...@amazon.com> wrote: > The early “break;” here is likely the xmin frozen reason as I found in the > other loop.
It looks that way. Since we're already very defensive when it comes to this xmin/xmax matching business, and we're defensive while following an update chain more generally, I wonder if we should be checking HeapTupleHeaderIsSpeculative() on versions >= 9.5 (versions with ON CONFLICT DO UPDATE, where t_ctid block number might actually be a speculative insertion token). Or, at least acknowledging that case in comments. I remember expressing concern that something like this was possible at the time that that went in. We certainly don't want to have heap_abort_speculative() "super delete" the wrong tuple in the event of item pointer recycling. There are at least defensive sanity checks that would turn that into an error within heap_abort_speculative(), so it wouldn't be a disaster if it was attempted. I don't think that it's possible in practice, and maybe it's sufficient that routines like heap_get_latest_tid() check for a sane item offset, which will discriminate against SpecTokenOffsetNumber, which must be well out of range for ItemIds on the page. Could be worth a comment. (I guess that heap_prune_chain() wouldn't need to be changed if we decide to add such comments, because the speculative tuple ItemId is going to be skipped over due to being ItemIdIsUsed() before we even get there.) -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
