Обсуждение: DROP STATISTICS results in "ERROR: tuple concurrently updated"

Поиск
Список
Период
Сортировка

DROP STATISTICS results in "ERROR: tuple concurrently updated"

От
Manuel Rigger
Дата:
Hi everyone,

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]?

Best,
Manuel

[1] https://www.postgresql.org/message-id/CA%2Bu7OA6pL%2B7Xm_NXHLenxffe3tCr3gTamVdr7zPjcWqW0RFM-A%40mail.gmail.com



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

От
Tom Lane
Дата:
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



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

От
Andres Freund
Дата:
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:
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