Re: DROP STATISTICS results in "ERROR: tuple concurrently updated"

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Manuel Rigger <rigger(dot)manuel(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: DROP STATISTICS results in "ERROR: tuple concurrently updated"
Date: 2019-07-23 20:00:39
Message-ID: 20190723200039.56d3acr6ojr4gkje@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Hi,

On 2019-07-23 14:14:56 -0400, Tom Lane wrote:
> Manuel Rigger <rigger(dot)manuel(at)gmail(dot)com> writes:
> > When running multiple threads that operate on distinct databases, a
> > "DROP STATISTICS" sometimes results in an error "ERROR: tuple
> > concurrently updated".

When you say "distinct databases", do you mean that each thread is on a
separate database, and that there's no actual concurrent access?

> I think it'd be worth running to ground, at least. One could imagine that
> the error is coming from one session trying to delete a statistics row
> that some other session has updated-and-not-yet-committed; but then the
> question is why there's not sufficient interlocking to avoid that.

For a second I thought it might be this bug:
https://www.postgresql.org/message-id/20190618231233.GA27470%40telsasoft.com

but it doesn't actually look like it's necessarily related. But it did
remind me that we ought to fix that, and that we didn't yet have an open
item...

Greetings,

Andres Freund

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message David Raymond 2019-07-23 21:42:06 RE: BUG #15922: Simple select with multiple exists filters returns duplicates from a primary key field
Previous Message David Raymond 2019-07-23 18:14:59 RE: BUG #15922: Simple select with multiple exists filters returns duplicates from a primary key field