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

From Andres Freund
Subject Re: Segfault on ANALYZE in SERIALIZABLE isolation
Date
Msg-id 20190518201241.nduhuqnmjkb7omyr@alap3.anarazel.de
Whole thread Raw
In response to Re: Segfault on ANALYZE in SERIALIZABLE isolation  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Segfault on ANALYZE in SERIALIZABLE isolation  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
Hi,

On 2019-05-18 15:48:47 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > 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.
 
> 
> Uh, what?  That's a *huge* regression.  See, eg, 7170268ef.  We
> really want ANALYZE to act as though it's reading a normal MVCC
> snapshot.

Hm? That's not new at all? In 11 we just do:

            switch (HeapTupleSatisfiesVacuum(&targtuple,
                                             OldestXmin,
                                             targbuffer))

I.e. unrelated to the tableam changes there's no mvcc snapshot in for
visibility determinations. And that's not changed, heap's implementation
still uses HTSV.  We do *hold* a snapshot, but that's all outside of
analyze.c afaik.

I've complained before that we're using a snapshot for analyze's
sampling scan in a lot of cases where it's not necessary, and that's a
very significant problem in production (where autvacuum doesn't cause
slowdowns, but autoanalyze does quite substantially).  But I'd not
change it just as an aside.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Segfault on ANALYZE in SERIALIZABLE isolation
Next
From: Peter Geoghegan
Date:
Subject: Re: itemptr_encode/itemptr_decode