Re: ANALYZE: ERROR: tuple already updated by self
От | Andres Freund |
---|---|
Тема | Re: ANALYZE: ERROR: tuple already updated by self |
Дата | |
Msg-id | 20190619000837.awy6j7h45ahd4vop@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: ANALYZE: ERROR: tuple already updated by self (Justin Pryzby <pryzby@telsasoft.com>) |
Ответы |
Re: ANALYZE: ERROR: tuple already updated by self
Re: ANALYZE: ERROR: tuple already updated by self |
Список | pgsql-hackers |
Hi, 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. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: