Re: pg_dump versus hash partitioning
От | Julien Rouhaud |
---|---|
Тема | Re: pg_dump versus hash partitioning |
Дата | |
Msg-id | 20230311033232.g6jgkuzxdawepsbe@jrouhaud обсуждение исходный текст |
Ответ на | Re: pg_dump versus hash partitioning (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: pg_dump versus hash partitioning
|
Список | pgsql-hackers |
On Fri, Mar 10, 2023 at 10:10:14PM -0500, Tom Lane wrote: > Julien Rouhaud <rjuju123@gmail.com> writes: > > Working on some side project that can cause dump of hash partitions to be > > routed to a different partition, I realized that --load-via-partition-root can > > indeed cause deadlock in such case without FK dependency or anything else. > > > The problem is that each worker will perform a TRUNCATE TABLE ONLY followed by > > a copy of the original partition's data in a transaction, and that obviously > > will lead to deadlock if the original and locked partition and the restored > > partition are different. > > Oh, interesting. I wonder if we can rearrange things to avoid that. The BEGIN + TRUNCATE is only there to avoid generating WAL records just in case the wal_level is minimal. I don't remember if that optimization still exists, but if yes we could avoid doing that if the server's wal_level is replica or higher? That's not perfect but it would help in many cases.
В списке pgsql-hackers по дате отправления: