Andres Freund <and...@anarazel.de> writes: > On 2019-06-18 00:32:17 -0400, Tom Lane wrote: >> Hmm, that's a pretty obvious mistake :-( but after some fooling around >> I've not been able to cause a crash with it. I wonder what test case >> you were using, on what platform?
> I suspect that's because the bug is "only" in the > HEAPTUPLE_DELETE_IN_PROGRESS case. And it's "harmless" as far as > crashing goes in the !TransactionIdIsCurrentTransactionId() case, > because as the tuple is sampled, we just return. And then there still > needs to be an actually dead row afterwards, to actually trigger > dereferencing the modified deadrows. And then acquire_sample_rows()'s > deadrows actually needs to point to something that causes crashes when > modified. Right, I'd come to the same conclusions last night, but failed to make a crasher example. Not sure why though, because my first try today blew up real good: --- \set N 10 create table bug as select generate_series(1,:N) f1; delete from bug where f1 = :N; begin; delete from bug; analyze verbose bug; rollback; drop table bug; --- On my machine, N smaller than 10 doesn't do it, but of course that will be very platform-specific. > Will fix tomorrow morning. OK. To save you the trouble of "git blame", it looks like 737a292b5de296615a715ddce2b2d83d1ee245c5 introduced this. regards, tom lane