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

From Richard Guo
Subject Re: Avoid lost result of recursion (src/backend/optimizer/util/inherit.c)
Date
Msg-id CAMbWs488Udp_Z7tUm0eUd3gtXZd3Wx2kDGhHat2Di+1UFkc3EA@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>)
Responses Re: Avoid lost result of recursion (src/backend/optimizer/util/inherit.c)  (David Rowley <dgrowleyml@gmail.com>)
List pgsql-hackers

On Wed, Dec 21, 2022 at 9:45 AM David Rowley <dgrowleyml@gmail.com> wrote:
Also, I think it might be better to take the opportunity to rewrite
the function to not use recursion. I don't quite see the need for it
here and it looks like that might have helped contribute to the
reported issue.  Can't we just write this as a while loop instead of
having the function call itself? It's not as if we need stack space
for keeping track of multiple parents. A child relation can only have
1 parent. It seems to me that we can just walk there by looping.
 
My best guess is that this function is intended to share the same code
pattern as in adjust_appendrel_attrs_multilevel.  The recursion is
needed as 'rel' can be more than one inheritance level below the top
parent.  I think we can keep the recursion, as in other similar
functions, as long as we make it right, as in attached patch.

Thanks
Richard
Attachment

pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: Force streaming every change in logical decoding
Next
From: Kyotaro Horiguchi
Date:
Subject: Re: Add LSN along with offset to error messages reported for WAL file read/write/validate header failures