Re: Patch proposal: New hooks in the connection path - Mailing list pgsql-hackers

From Bharath Rupireddy
Subject Re: Patch proposal: New hooks in the connection path
Date
Msg-id CALj2ACUt0GEn3SBcxA+oLfq2fabFPWse-xCFsz-D6PqECe58Og@mail.gmail.com
Whole thread Raw
In response to Re: Patch proposal: New hooks in the connection path  ("Drouvot, Bertrand" <bdrouvot@amazon.com>)
Responses Re: Patch proposal: New hooks in the connection path
List pgsql-hackers
On Tue, Aug 16, 2022 at 1:31 PM Drouvot, Bertrand <bdrouvot@amazon.com> wrote:
>
> On 8/14/22 7:52 AM, Gurjeet Singh wrote:
> > On Mon, Aug 8, 2022 at 3:51 AM Drouvot, Bertrand <bdrouvot@amazon.com> wrote:
>
> > I think we can reduce the number of places the hook is called, if we
> > call the hook from proc_exit(), and at all the other places we simply set
> > a global variable to signify the reason for the failure. The case of
> > _exit(1) from the signal-handler cannot use such a mechanism, but I
> > think all the other cases of interest can simply register one of the
> > FCET_* values, and let the call from proc_exit() pass that value
> > to the hook.
>
> That looks like a good idea to me. I'm tempted to rewrite the patch that
> way (and addressing the first comment in the same time).
>
> Curious to hear about others hackers thoughts too.

IMO, calling the hook from proc_exit() is not a good design as
proc_exit() is a generic code called from many places in the source
code, even the simple code of kind  if(call_failed_conn_hook) {
falied_conn_hook(params);} can come in the way of many exit code paths
which is undesirable, and the likelihood of introducing new bugs may
increase.

-- 
Bharath Rupireddy
RDS Open Source Databases: https://aws.amazon.com/rds/postgresql/



pgsql-hackers by date:

Previous
From: "Drouvot, Bertrand"
Date:
Subject: Re: Patch proposal: New hooks in the connection path
Next
From: "Drouvot, Bertrand"
Date:
Subject: Re: Patch proposal: New hooks in the connection path