Re: BUG #15946: "duplicate key" error on ANALYZE of table partitions in transaction - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #15946: "duplicate key" error on ANALYZE of table partitions in transaction
Date
Msg-id 618.1565446996@sss.pgh.pa.us
Whole thread Raw
In response to BUG #15946: "duplicate key" error on ANALYZE of table partitions in transaction  (PG Bug reporting form <noreply@postgresql.org>)
Responses Re: BUG #15946: "duplicate key" error on ANALYZE of table partitionsin transaction  (naveen mahadevuni <nmahadevuni@gmail.com>)
List 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 by date:

Previous
From: PG Bug reporting form
Date:
Subject: BUG #15946: "duplicate key" error on ANALYZE of table partitions in transaction
Next
From: PG Bug reporting form
Date:
Subject: BUG #15947: Worse plan is chosen after giving the planner more freedom (partitionwise join)