Hi, On May 18, 2019 11:55:01 AM PDT, Tom Lane <t...@sss.pgh.pa.us> wrote: >I wrote: >> Sergei Kornilov <s...@zsrv.org> writes: >>> I can reproduce with: >>> set default_transaction_isolation TO serializable ; >>> analyze ; > >> 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?
Not quite - that was about the DML callbacks, this is about the scan itself. And while we have a snapshot allocated, the analyze version of the beginscan intentionally doesn't take a snapshot. >Bisecting confirms that this broke at > >commit 737a292b5de296615a715ddce2b2d83d1ee245c5 >Author: Andres Freund <and...@anarazel.de> >Date: Sat Mar 30 16:21:09 2019 -0700 > > tableam: VACUUM and ANALYZE support. > >I'd thought possibly this had something to do with bb16aba50 (Enable >parallel query with SERIALIZABLE isolation) but the bisection result >makes it pretty clear that it's just a tableam API screwup. I'm not yet at my computer, but I think all that's needed is to expand the check that prevents the predicate lock to be acquired for heap type scans to the analyze case. I'll check it in a few. Andres -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
