On Tue, Jun 7, 2016 at 7:00 PM, Peter Geoghegan <pg@heroku.com> wrote:
> So, if it's not coming from a cascading foreign key, as I suspect,
> then it's definitely coming from some other user-visible delete
> (Something that can reach heap_delete(), very probably through
> ExecDelete()). I'm very curious about what that is.
I now think it's coming through simple_heap_delete(), which in turn is
called by toast_delete_datum(). It seems likely that the
toast_delete() call in heap_abort_speculative() is how we get to
heap_delete(). So, I withdraw my remarks about it being impossible for
a "plain" ON CONFLICT DO UPDATE to reach heap_delete() (unless you
define a "plain" UPSERT as one necessarily not involving a TOAST
table).
I notice that both bug reports involve JSON documents that are
typically fairly large -- large enough to be stored externally by
TOAST. heap_abort_speculative() generally isn't called all that often,
even when there are plenty of conflicts, and UPSERTs won't usually
involve very large datums. It makes sense that it took this long to
get a bug report like this.
I'm going to work on a reproduction of the bug by modifying the
jjanes_upsert stress-testing suite. My immediate suspicion is that we
need to rethink the 9.5 changes to HeapTupleSatisfiesToast() in light
of this.
--
Peter Geoghegan
