Horton

Re: pg_dump versus hash partitioning

Julien Rouhaud <rjuju123@gmail.com>

View thread View on postgr.es
From: Julien Rouhaud <rjuju123@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andrew Dunstan <andrew@dunslane.net>, Alvaro Herrera <alvherre@alvh.no-ip.org>, David Rowley <dgrowleyml@gmail.com>, Peter Geoghegan <pg@bowt.ie>, Robert Haas <robertmhaas@gmail.com>, pgsql-hackers@lists.postgresql.org, Andrew <pgsqlhackers@andrewrepp.com>
Date: 2023-03-11T03:32:32Z
Lists: 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.

Commits

  1. Simplify and speed up pg_dump's creation of parent-table links.

  2. Fix pg_dump for hash partitioning on enum columns.