Re: Avoid lost result of recursion (src/backend/optimizer/util/inherit.c) - Mailing list pgsql-hackers

From David Rowley
Subject Re: Avoid lost result of recursion (src/backend/optimizer/util/inherit.c)
Date
Msg-id CAApHDvpJgZ35NDac3fYi=VXjJma8AyyBFXQ2jM8RVVLRR00QmQ@mail.gmail.com
Whole thread Raw
In response to Re: Avoid lost result of recursion (src/backend/optimizer/util/inherit.c)  (Richard Guo <guofenglinux@gmail.com>)
Responses Re: Avoid lost result of recursion (src/backend/optimizer/util/inherit.c)  (Ranier Vilela <ranier.vf@gmail.com>)
Re: Avoid lost result of recursion (src/backend/optimizer/util/inherit.c)  (Amit Langote <amitlangote09@gmail.com>)
List pgsql-hackers
On Fri, 23 Dec 2022 at 17:04, Richard Guo <guofenglinux@gmail.com> wrote:
> Thanks for the test!  I looked at this and found that with WCO
> constraints we can also hit the buggy code.  Based on David's test case,
> I came up with the following in the morning.

I ended up going with a WCO option test in the end.  I wanted to steer
clear of having a test that has expected broken results from the
generated column code.  Also, I just couldn't help thinking the
generated column test felt like it was just glued on the end and not
really in the correct place in the file.

I've put the new WCO test in along with the existing one.  I also
considered modifying one of the existing tests to add another
partitioning level, but I ended up staying clear of that as I felt
like it caused a bit more churn than I wanted with an existing test.
The test I put together tests for the bug and also checks the WCO
works by not updating the row that's outside of the scope of the WCO
view and updating the row that is in the scope of the view.

I've now pushed your fix plus that test.

It feels a bit like famine to feast when it comes to tests for this bug today.

David



pgsql-hackers by date:

Previous
From: John Naylor
Date:
Subject: Re: [PoC] Improve dead tuple storage for lazy vacuum
Next
From: "Hayato Kuroda (Fujitsu)"
Date:
Subject: RE: Exit walsender before confirming remote flush in logical replication