On Wed, Apr 16, 2025 at 12:19 AM Tom Lane wrote:
>
> Ashutosh Bapat writes:
> > On Mon, Apr 14, 2025 at 11:14 PM Tom Lane wrote:
> >> This is disastrous for assorted reasons. The ALTER ADD CONSTRAINT
> >> command might fail outright if we've loaded data for the referencing
> >> table but not th
Ashutosh Bapat writes:
> On Mon, Apr 14, 2025 at 11:14 PM Tom Lane wrote:
>> This is disastrous for assorted reasons. The ALTER ADD CONSTRAINT
>> command might fail outright if we've loaded data for the referencing
>> table but not the referenced table.
> There's a comment in getConstraints()
>
On Mon, Apr 14, 2025 at 11:14 PM Tom Lane wrote:
>
> I wrote:
> > Here's a draft patch for this. It seems to fix the problem in
> > light testing.
>
> I realized that the "repro" I had for this isn't testing the same
> thing that Dimitrios is seeing; what it is exposing looks more like
> a bug or
On 15 April 2025 18:18:41 CEST, Tom Lane wrote:
>Dimitrios Apostolou writes:
>> I only got the "ERROR: deadlock detected" message once, with pg_restore
>> compiled from master branch.
>
>Oh, hmm ... do you recall just when on the master branch? I'm
>wondering if it was before or after 14e87ffa5
Dimitrios Apostolou writes:
> I only got the "ERROR: deadlock detected" message once, with pg_restore
> compiled from master branch.
Oh, hmm ... do you recall just when on the master branch? I'm
wondering if it was before or after 14e87ffa5 (2024-11-08).
If it was after, then it might have been
On Mon, 14 Apr 2025, Tom Lane wrote:
I wrote:
Here's a draft patch for this. It seems to fix the problem in
light testing.
I realized that the "repro" I had for this isn't testing the same
thing that Dimitrios is seeing; what it is exposing looks more like
a bug or at least a behavioral chan
I wrote:
> Here's a draft patch for this. It seems to fix the problem in
> light testing.
I realized that the "repro" I had for this isn't testing the same
thing that Dimitrios is seeing; what it is exposing looks more like
a bug or at least a behavioral change due to the v18 work to record
not-n
I wrote:
> I think that the most intellectually rigorous solution is to
> generate dummy TABLE DATA objects for partitioned tables, which
> don't actually contain data but merely carry dependencies on
> each of the child tables' TABLE DATA objects.
Here's a draft patch for this. It seems to fix t
Looking into the complaint at [1], I find that pg_restore really gets
it quite wrong when trying to do a parallel restore of partitioned
tables with foreign key constraints. The historical way that we
got parallel restore to work correctly with FK constraints is:
1. The dump file shows dependenci
