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

  1. Fix "ANALYZE t, t" inside a transaction block.