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