Re: Segfault on ANALYZE in SERIALIZABLE isolation - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Segfault on ANALYZE in SERIALIZABLE isolation
Date
Msg-id 21507.1558192746@sss.pgh.pa.us
Whole thread Raw
In response to Re: Segfault on ANALYZE in SERIALIZABLE isolation  (Sergei Kornilov <sk@zsrv.org>)
Responses Re: Segfault on ANALYZE in SERIALIZABLE isolation
List pgsql-hackers
Sergei Kornilov <sk@zsrv.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@entry=0x7f53e9a525f8, snapshot=snapshot@entry=0x0) at predicate.c:2507
> #2  0x0000562395b78a14 in heap_beginscan (relation=0x7f53e9a525f8, snapshot=0x0, nkeys=0, key=0x0, parallel_scan=0x0,
allow_strat=<optimizedout>,  
>     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@entry=0x7f53e9a525f8, elevel=elevel@entry=13, rows=rows@entry=0x562396f01dd0,
targrows=targrows@entry=30000, 
>     totalrows=totalrows@entry=0x7ffd0603e498, totaldeadrows=totaldeadrows@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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Multivariate MCV stats can leak data to unprivileged users
Next
From: Alexander Lakhin
Date:
Subject: Fix some unique identifiers/entities