On 2020-09-04 12:41:23 -0400, Tom Lane wrote:
> Alvaro Herrera writes:
> > On 2020-Sep-03, Tom Lane wrote:
> >> I'm inclined to think that the best fix is to put
> >>
> >> begin;
> >> lock table [fast_emp4000];
> >> ...
> >> commit;
> >>
> >> around the DROP CASCADE.
>
> > Yeah, sounds good.
>
Alvaro Herrera writes:
> On 2020-Sep-03, Tom Lane wrote:
>> I'm inclined to think that the best fix is to put
>>
>> begin;
>> lock table [fast_emp4000];
>> ...
>> commit;
>>
>> around the DROP CASCADE.
> Yeah, sounds good.
Done.
regards, tom lane
On 2020-Sep-03, Tom Lane wrote:
> So it's not hard to understand the problem: DROP of an index AM, cascading
> to an index, will need to acquire lock on the index and then lock on the
> index's table. Any other operation on the table, like say autovacuum,
> is going to acquire locks in the other
Thomas Munro writes:
> On Fri, Sep 4, 2020 at 2:13 PM Tom Lane wrote:
>> I'm inclined to think that the best fix is to put
>>
>> begin;
>> lock table tenk2;
>> ...
>> commit;
> Makes sense, except s/tenk2/fast_emp4000/, no?
Sorry, thinko ...
regards, tom lane
On Fri, Sep 4, 2020 at 2:13 PM Tom Lane wrote:
> (There might be more such failures, but I only looked back six months,
> and these two are all I found in that window.)
Right:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=conchuela&dt=2020-09-03%2023:00:36
| HEAD | Dragonfl
conchuela just showed an unusual failure:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=conchuela&dt=2020-09-03%2023%3A00%3A36
The core of it is a deadlock failure in create_am.sql; there's then
some follow-on noise from not having successfully dropped the test AM.
The deadlock looks li
