Date: Sat, 11 Mar 2023 11:32:32 +0800
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>
Subject: Re: pg_dump versus hash partitioning
Message-ID: <20230311033232.g6jgkuzxdawepsbe@jrouhaud>
References: <CA+TgmoYJ+3XpW_iYapXN3gwq2MECi7GH8BxuwKFCQPOzLaa3OQ@mail.gmail.com>
 <CAH2-Wz=cMRoYHeoac7kscdDNBSYzHKgMvSHX5CFEoE66rimk8A@mail.gmail.com>
 <1425446.1675291093@sss.pgh.pa.us>
 <CAApHDvqJM5HxhZSnxESENAHLxTZ=eXKKHxeHfvVe1E8v28woDA@mail.gmail.com>
 <1440373.1675299790@sss.pgh.pa.us>
 <a7ef6212-f9fe-6826-9640-5dac54327140@dunslane.net>
 <1533086.1675349554@sss.pgh.pa.us>
 <1912821.1676402493@sss.pgh.pa.us>
 <20230311030154.pg63uspio35h4a6t@jrouhaud>
 <1078804.1678504214@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1078804.1678504214@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/20230311033232.g6jgkuzxdawepsbe%40jrouhaud>
Precedence: bulk

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.