Andres Freund <andres@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