DROP STATISTICS results in "ERROR: tuple concurrently updated"

Manuel Rigger <rigger.manuel@gmail.com> writes:

When running multiple threads that operate on distinct databases, a
"DROP STATISTICS" sometimes results in an error "ERROR: tuple
concurrently updated". Would it be useful to make this error
reproducible, or could this be expected, similar to the VACUUM
deadlocks [1]?

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.

regards, tom lane

Hi,

On 2019-07-23 14:14:56 -0400, Tom Lane wrote:

Manuel Rigger <rigger.manuel@gmail.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:
/messages/by-id/20190618231233.GA27470@telsasoft.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