Re: BUG #15946: "duplicate key" error on ANALYZE of table partitions in transaction
naveen mahadevuni <nmahadevuni@gmail.com>
From: naveen mahadevuni <nmahadevuni@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: ladayaroslav@yandex.ru, pgsql-bugs@lists.postgresql.org
Date: 2019-08-13T17:35:39Z
Lists: pgsql-bugs
hi Tom, I would like to start contributing to postgres, would like to fix this one if it hasn't already been done. Thanks, Naveen On Sat, Aug 10, 2019 at 7:53 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > 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 > > >
Commits
-
Fix "ANALYZE t, t" inside a transaction block.
- ceb850d4a30c 11.6 landed
- cabe0f298ea7 13.0 landed
- 6ce0366be2a3 12.0 landed