Re: ANALYZE: ERROR: tuple already updated by self - Mailing list pgsql-hackers

From Tomas Vondra
Subject Re: ANALYZE: ERROR: tuple already updated by self
Date
Msg-id 20190730181134.3d6t6yd6rnmoeuv3@development
Whole thread Raw
In response to Re: ANALYZE: ERROR: tuple already updated by self  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
List 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




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: TopoSort() fix
Next
From: Andres Freund
Date:
Subject: typesafe printf hackery