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
|
Список | 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 по дате отправления: