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)
Список
Дерево обсуждения
pg_dump versus hash partitioning Tom Lane <tgl@sss.pgh.pa.us>
Re: pg_dump versus hash partitioning Robert Haas <robertmhaas@gmail.com>
Re: pg_dump versus hash partitioning Tom Lane <tgl@sss.pgh.pa.us>
Re: pg_dump versus hash partitioning Robert Haas <robertmhaas@gmail.com>
Re: pg_dump versus hash partitioning Tom Lane <tgl@sss.pgh.pa.us>
Re: pg_dump versus hash partitioning Robert Haas <robertmhaas@gmail.com>
Re: pg_dump versus hash partitioning Tom Lane <tgl@sss.pgh.pa.us>
Re: pg_dump versus hash partitioning Robert Haas <robertmhaas@gmail.com>
Re: pg_dump versus hash partitioning Peter Geoghegan <pg@bowt.ie>
Re: pg_dump versus hash partitioning Tom Lane <tgl@sss.pgh.pa.us>
Re: pg_dump versus hash partitioning Robert Haas <robertmhaas@gmail.com>
Re: pg_dump versus hash partitioning Tom Lane <tgl@sss.pgh.pa.us>
Re: pg_dump versus hash partitioning Robert Haas <robertmhaas@gmail.com>
Re: pg_dump versus hash partitioning Tom Lane <tgl@sss.pgh.pa.us>
Re: pg_dump versus hash partitioning Laurenz Albe <laurenz.albe@cybertec.at>
Re: pg_dump versus hash partitioning Peter Geoghegan <pg@bowt.ie>
Re: pg_dump versus hash partitioning Alvaro Herrera <alvherre@alvh.no-ip.org>
Re: pg_dump versus hash partitioning Tom Lane <tgl@sss.pgh.pa.us>
Re: pg_dump versus hash partitioning Peter Geoghegan <pg@bowt.ie>
Re: pg_dump versus hash partitioning Robert Haas <robertmhaas@gmail.com>
Re: pg_dump versus hash partitioning Tom Lane <tgl@sss.pgh.pa.us>
Re: pg_dump versus hash partitioning Peter Geoghegan <pg@bowt.ie>
Re: pg_dump versus hash partitioning Tom Lane <tgl@sss.pgh.pa.us>
Re: pg_dump versus hash partitioning David Rowley <dgrowleyml@gmail.com>
Re: pg_dump versus hash partitioning Tom Lane <tgl@sss.pgh.pa.us>
Re: pg_dump versus hash partitioning Andrew Dunstan <andrew@dunslane.net>
Re: pg_dump versus hash partitioning Tom Lane <tgl@sss.pgh.pa.us>
Re: pg_dump versus hash partitioning Tom Lane <tgl@sss.pgh.pa.us>
Re: pg_dump versus hash partitioning Julien Rouhaud <rjuju123@gmail.com>
Re: pg_dump versus hash partitioning Tom Lane <tgl@sss.pgh.pa.us>
Re: pg_dump versus hash partitioning Julien Rouhaud <rjuju123@gmail.com>
Re: pg_dump versus hash partitioning Tom Lane <tgl@sss.pgh.pa.us>
Re: pg_dump versus hash partitioning Julien Rouhaud <rjuju123@gmail.com>
Re: pg_dump versus hash partitioning Tom Lane <tgl@sss.pgh.pa.us>
Re: pg_dump versus hash partitioning Julien Rouhaud <rjuju123@gmail.com>
Re: pg_dump versus hash partitioning Tom Lane <tgl@sss.pgh.pa.us>
Re: pg_dump versus hash partitioning Julien Rouhaud <rjuju123@gmail.com>
Re: pg_dump versus hash partitioning Tom Lane <tgl@sss.pgh.pa.us>
Re: pg_dump versus hash partitioning Julien Rouhaud <rjuju123@gmail.com>
Re: pg_dump versus hash partitioning Justin Pryzby <pryzby@telsasoft.com>
Re: pg_dump versus hash partitioning Tom Lane <tgl@sss.pgh.pa.us>
Re: pg_dump versus hash partitioning Robert Haas <robertmhaas@gmail.com>
Re: pg_dump versus hash partitioning Tom Lane <tgl@sss.pgh.pa.us>
Re: pg_dump versus hash partitioning Robert Haas <robertmhaas@gmail.com>
Re: pg_dump versus hash partitioning Tom Lane <tgl@sss.pgh.pa.us>
Re: pg_dump versus hash partitioning Robert Haas <robertmhaas@gmail.com>
Re: pg_dump versus hash partitioning Tom Lane <tgl@sss.pgh.pa.us>
Re: pg_dump versus hash partitioning "David G. Johnston" <david.g.johnston@gmail.com>
Re: pg_dump versus hash partitioning Peter Geoghegan <pg@bowt.ie>
On Fri, Mar 10, 2023 at 10:10:14PM -0500, Tom Lane wrote: > Julien Rouhaud 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 по дате отправления
От: Amit Kapila
Дата: