Re: RFC: Logging plan of the running query - Mailing list pgsql-hackers

From Ashutosh Bapat
Subject Re: RFC: Logging plan of the running query
Date
Msg-id CAExHW5t49R=J6Tf=yctvi7M07-Z-o1vY68hy_Ub2aF=kbTXeeQ@mail.gmail.com
Whole thread Raw
In response to Re: RFC: Logging plan of the running query  (Julien Rouhaud <rjuju123@gmail.com>)
List pgsql-hackers
On Mon, Feb 26, 2024 at 1:25 PM Julien Rouhaud <rjuju123@gmail.com> wrote:
> >
> > >
> > > #define CHECK_FOR_INTERRUPTS_X(x, f, CFI_IMPL, ...) CFI_IMPL
> > >
> > > #define CHECK_FOR_INTERRUPTS(...) \
> > >         CHECK_FOR_INTERRUPTS_X(, ##__VA_ARGS__, \
> > >                                                         CHECK_FOR_INTERRUPTS_1(__VA_ARGS__), \
> > >                                                         CHECK_FOR_INTERRUPTS_0(__VA_ARGS__) \
> > >                                                 )
> > >
> > > We would have to duplicate the current CFI body, but it should never really
> > > change, and we shouldn't end up with more than 2 overloads anyway so I don't
> > > see it being much of a problem.
> >
> > Why do we need this complex macro?
>
> So that client code can use either CHECK_FOR_INTERRUPTS() or
> CHECK_FOR_INTERRUPTS(flag) rather that transforming every single
> CHECK_FOR_INTERRUPTS() to CHECK_FOR_INTERRUPTS(0), which was Robert's
> complaint about this approach.

It might be better to just create two marcos  (with names like
CHECK_FOR_INTERRUPTS() and CHECK_FOR_INTERRUPTS_SAFE()) to call
ProcessInterrupt() directly and modify ProcessInterrupts() to accept
the flag (and if required call CFIFlagHandler() additionally). Last
macro is hard to understand.

--
Best Wishes,
Ashutosh Bapat



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Sequence Access Methods, round two
Next
From: Bertrand Drouvot
Date:
Subject: Re: Injection points: some tools to wait and wake