Re: BUG #15946: "duplicate key" error on ANALYZE of table partitions in transaction
От | Tom Lane |
---|---|
Тема | Re: BUG #15946: "duplicate key" error on ANALYZE of table partitions in transaction |
Дата | |
Msg-id | 618.1565446996@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | BUG #15946: "duplicate key" error on ANALYZE of table partitions in transaction (PG Bug reporting form <noreply@postgresql.org>) |
Ответы |
Re: BUG #15946: "duplicate key" error on ANALYZE of table partitionsin transaction
|
Список | pgsql-bugs |
PG Bug reporting form <noreply@postgresql.org> writes: > Running this: > ... > Throws this error: > ERROR: duplicate key value violates unique constraint "pg_statistic_relid_att_inh_index" > DETAIL: Key (starelid, staattnum, stainherit)=(61056, 1, f) already exists. Hm, you don't need all the fancy partitioning stuff: regression=# create table t as select generate_series(1,10) x; SELECT 10 regression=# begin; BEGIN regression=# analyze t, t; ERROR: duplicate key value violates unique constraint "pg_statistic_relid_att_inh_index" DETAIL: Key (starelid, staattnum, stainherit)=(35836, 1, f) already exists. It appears to work fine without the BEGIN: regression=# analyze t, t; ANALYZE but then regression=# begin; BEGIN regression=# analyze t, t; ERROR: tuple already updated by self I think the conclusion is that if we aren't using per-table transactions we'd better do a CommandCounterIncrement between tables in vacuum()'s loop. regards, tom lane
В списке pgsql-bugs по дате отправления: