Re: Segfault on ANALYZE in SERIALIZABLE isolation

Hi,

On May 18, 2019 11:55:01 AM PDT, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>I wrote:
>> Sergei Kornilov <sk(at)zsrv(dot)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 <andres(at)anarazel(dot)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.