Re: pg_dump versus hash partitioning

Поиск
Список
Период
Сортировка
Искать
От
Julien Rouhaud
Тема
Re: pg_dump versus hash partitioning
Дата
Msg-id
20230311033232.g6jgkuzxdawepsbe@jrouhaud
Ответ на
Список
Дерево обсуждения
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
Дата:
От: Andres Freund
Дата:
Сообщение: Re: cpluspluscheck vs ICU
FAQ