Re: ALTER TABLE SET ACCESS METHOD on partitioned tables

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: ALTER TABLE SET ACCESS METHOD on partitioned tables
Дата
Msg-id 1464385.1712034366@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: ALTER TABLE SET ACCESS METHOD on partitioned tables  (Justin Pryzby <pryzby@telsasoft.com>)
Ответы Re: ALTER TABLE SET ACCESS METHOD on partitioned tables  (Michael Paquier <michael@paquier.xyz>)
Список pgsql-hackers
Justin Pryzby <pryzby@telsasoft.com> writes:
> On Sun, Mar 31, 2024 at 12:00:00PM +0300, Alexander Lakhin wrote:
>> I've stumbled upon a test failure caused by the test query added in that
>> commit:
>> +ERROR:  deadlock detected
>> +DETAIL:  Process 3076180 waits for AccessShareLock on relation 1259 of database 16386; blocked by process 3076181.
>> +Process 3076181 waits for AccessShareLock on relation 2601 of database 16386; blocked by process 3076180.

> I think means that, although it was cute to use pg_am in the reproducer
> given in the problem report, it's not a good choice to use here in the
> sql regression tests.

Another case here:

https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=sevengill&dt=2024-04-02%2001%3A32%3A17

AFAICS, e2395cdbe posits that taking exclusive lock on pg_am in the
middle of a bunch of concurrent regression scripts couldn't possibly
cause any problems.  Really?

            regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Bertrand Drouvot
Дата:
Сообщение: Re: Synchronizing slots from primary to standby
Следующее
От: Jeff Davis
Дата:
Сообщение: Re: Table AM Interface Enhancements