| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Manuel Rigger <rigger(dot)manuel(at)gmail(dot)com> |
| Cc: | 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 18:14:56 |
| Message-ID: | 8683.1563905696@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
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". 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
| From | Date | Subject | |
|---|---|---|---|
| Next 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 |
| Previous Message | Tom Lane | 2019-07-23 17:52:04 | Re: BUG #15922: Simple select with multiple exists filters returns duplicates from a primary key field |