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
