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

From Amit Langote
Subject Re: Avoid lost result of recursion (src/backend/optimizer/util/inherit.c)
Date
Msg-id CA+HiwqELTNSbjHu5kc75jtZm7RE3=Q-zxoq6Ph51hgVDBdo+eQ@mail.gmail.com
Whole thread Raw
In response to Re: Avoid lost result of recursion (src/backend/optimizer/util/inherit.c)  (David Rowley <dgrowleyml@gmail.com>)
List pgsql-hackers
On Fri, Dec 23, 2022 at 9:10 PM David Rowley <dgrowleyml@gmail.com> wrote
> 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.

Thanks for working on this.

-- 
Thanks, Amit Langote
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: [PATCH] Teach pg_waldump to extract FPIs from the WAL
Next
From: Amit Kapila
Date:
Subject: Re: Force streaming every change in logical decoding