Re: Segfault on ANALYZE in SERIALIZABLE isolation

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Sergei Kornilov <sk(at)zsrv(dot)org>, Joe Wildish <joe-postgresql(dot)org(at)elusive(dot)cx>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Segfault on ANALYZE in SERIALIZABLE isolation
Date: 2019-05-18 20:12:41
Message-ID: 20190518201241.nduhuqnmjkb7omyr@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2019-05-18 15:48:47 -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2019-05-18 20:21:38 Re: itemptr_encode/itemptr_decode
Previous Message Tom Lane 2019-05-18 19:48:47 Re: Segfault on ANALYZE in SERIALIZABLE isolation