Re: Segfault on ANALYZE in SERIALIZABLE isolation

Sergei Kornilov <sk(at)zsrv(dot)org> writes:
> I can reproduce with:

> set default_transaction_isolation TO serializable ;
> analyze ;

> Here is backtrace:

> #0 SerializationNeededForRead (snapshot=0x0, relation=0x7f53e9a525f8) at predicate.c:530
> #1 PredicateLockRelation (relation=relation(at)entry=0x7f53e9a525f8, snapshot=snapshot(at)entry=0x0) at predicate.c:2507
> #2 0x0000562395b78a14 in heap_beginscan (relation=0x7f53e9a525f8, snapshot=0x0, nkeys=0, key=0x0, parallel_scan=0x0, allow_strat=<optimized out>,
> allow_sync=false, allow_pagemode=true, is_bitmapscan=false, is_samplescan=true, temp_snap=false) at heapam.c:1180
> #3 0x0000562395c782d7 in table_beginscan_analyze (rel=0x7f53e9a525f8) at ../../../src/include/access/tableam.h:786
> #4 acquire_sample_rows (onerel=onerel(at)entry=0x7f53e9a525f8, elevel=elevel(at)entry=13, rows=rows(at)entry=0x562396f01dd0, targrows=targrows(at)entry=30000,
> totalrows=totalrows(at)entry=0x7ffd0603e498, totaldeadrows=totaldeadrows(at)entry=0x7ffd0603e490) at analyze.c:1032

So the problem is that something is passing a null snapshot to something
that isn't expecting that. This seems closely related to the tableam
API issue that was being debated a day or two back about whether it's
ever valid to hand a null snapshot to an AM. Andres, which layer do
you think is at fault here?

regards, tom lane