Re: ANALYZE: ERROR: tuple already updated by self

From: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Justin Pryzby <pryzby(at)telsasoft(dot)com>, Tomas Vondra <tv(at)fuzzy(dot)cz>, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: ANALYZE: ERROR: tuple already updated by self
Date: 2019-07-30 18:11:34
Message-ID: 20190730181134.3d6t6yd6rnmoeuv3@development
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2019-07-30 18:18:45 typesafe printf hackery
Previous Message Tom Lane 2019-07-30 18:10:13 Re: TopoSort() fix