Re: ANALYZE: ERROR: tuple already updated by self
Tomas Vondra <tomas.vondra@2ndquadrant.com>
From: Tomas Vondra <tomas.vondra@2ndquadrant.com>
To: Andres Freund <andres@anarazel.de>
Cc: Justin Pryzby <pryzby@telsasoft.com>, Tomas Vondra <tv@fuzzy.cz>, Dean Rasheed <dean.a.rasheed@gmail.com>, pgsql-hackers@postgresql.org
Date: 2019-07-30T18:11:34Z
Lists: pgsql-hackers
On Mon, Jul 29, 2019 at 12:18:33PM +0200, Tomas Vondra wrote: >On Sun, Jul 28, 2019 at 09:53:20PM -0700, Andres Freund wrote: >>Hi, >> >>On 2019-07-28 21:21:51 +0200, Tomas Vondra wrote: >>>AFAICS it applies to 10+ versions, because that's where extended stats >>>were introduced. We certainly can't mess with catalogs there, so this is >>>about the only backpatchable fix I can think of. >> >>AFAIU the inh version wouldn't be used anyway, and this has never >>worked. So I think it's imo fine to fix it that way for < master. For >>master we should have something better, even if perhaps not immediately. >> > >Agreed. I'll get the simple fix committed soon, and put a TODO on my >list for pg13. > I've pushed the simple fix - I've actually simplified it a bit further by simply not calling the BuildRelationExtStatistics() at all when inh=true, instead of passing the flag to BuildRelationExtStatistics() and making the decision there. The function is part of public API, so this would be an ABI break (although it's unlikely anyone else is calling the function). regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Commits
-
Don't build extended statistics on inheritance trees
- 859b3003de87 10.10 landed
- 4dbf70b2ff1e 11.5 landed
- e1947f6c3ed8 12.0 landed
- 14ef15a22246 13.0 landed