From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> |
Cc: | Justin Pryzby <pryzby(at)telsasoft(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: XX000: tuple concurrently deleted during DROP STATISTICS |
Date: | 2023-11-08 15:52:28 |
Message-ID: | 683594.1699458748@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> writes:
> On 11/8/23 16:10, Justin Pryzby wrote:
>> I found this in our logs, and reproduced it under v11-v16.
>>
>> CREATE TABLE t(a int, b int);
>> INSERT INTO t SELECT generate_series(1,999);
>> CREATE STATISTICS t_stats ON a,b FROM t;
>>
>> while :; do psql postgres -qtxc "ANALYZE t"; done &
>> while :; do psql postgres -qtxc "begin; DROP STATISTICS t_stats"; done &
>>
>> It's known that concurrent DDL can hit elog(). But in this case,
>> there's only one DDL operation.
> AFAICS this happens because store_statext (after ANALYZE builds the new
> statistics) does this:
Shouldn't DROP STATISTICS be taking a lock on the associated table
that is strong enough to lock out ANALYZE?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2023-11-08 15:55:07 | Re: meson documentation build open issues |
Previous Message | Tomas Vondra | 2023-11-08 15:27:40 | Re: XX000: tuple concurrently deleted during DROP STATISTICS |