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
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 |