From: | Julien Rouhaud <rjuju123(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, David Rowley <dgrowleyml(at)gmail(dot)com>, Peter Geoghegan <pg(at)bowt(dot)ie>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Andrew <pgsqlhackers(at)andrewrepp(dot)com> |
Subject: | Re: pg_dump versus hash partitioning |
Date: | 2023-03-11 03:32:32 |
Message-ID: | 20230311033232.g6jgkuzxdawepsbe@jrouhaud |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Mar 10, 2023 at 10:10:14PM -0500, Tom Lane wrote:
> Julien Rouhaud <rjuju123(at)gmail(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2023-03-11 03:37:27 | Re: cpluspluscheck vs ICU |
Previous Message | Amit Kapila | 2023-03-11 03:30:49 | Re: [PATCH] Use indexes on the subscriber when REPLICA IDENTITY is full on the publisher |