From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | 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> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: ANALYZE: ERROR: tuple already updated by self |
Date: | 2019-07-23 20:01:27 |
Message-ID: | 20190723200127.moumhmj3z4b4dohg@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2019-06-18 17:08:37 -0700, Andres Freund wrote:
> On 2019-06-18 18:48:58 -0500, Justin Pryzby wrote:
> > Ah: the table is an inheritence parent. If I uninherit its child, there's no
> > error during ANALYZE. MV stats on the child are ok:
>
> It's a "classical" inheritance parent, not a builtin-partitioning type
> of parent, right? And it contains data?
>
> I assume it ought to not be too hard to come up with a reproducer
> then...
>
> I think the problem is pretty plainly that for inheritance tables we'll
> try to store extended statistics twice. And thus end up updating the
> same row twice.
>
> > #6 0x0000000000588346 in do_analyze_rel (onerel=0x7fee16140de8, options=2, params=0x7ffe5b6bf8b0, va_cols=0x0, acquirefunc=0x492b4, relpages=36, inh=true, in_outer_xact=false, elevel=13) at analyze.c:627
>
> /* Build extended statistics (if there are any). */
> BuildRelationExtStatistics(onerel, totalrows, numrows, rows, attr_cnt,
> vacattrstats);
>
> Note that for plain statistics we a) pass down the 'inh' flag to the
> storage function, b) stainherit is part of pg_statistics' key:
>
> Indexes:
> "pg_statistic_relid_att_inh_index" UNIQUE, btree (starelid, staattnum, stainherit)
>
>
> Tomas, I think at the very least extended statistics shouldn't be built
> when building inherited stats. But going forward I think we should
> probably have it as part of the key for pg_statistic_ext.
Tomas, ping?
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Cramer | 2019-07-23 20:37:27 | Re: Procedure support improvements |
Previous Message | David Steele | 2019-07-23 20:00:29 | Re: Fetching timeline during recovery |