Re: ResourceOwner refactoring - Mailing list pgsql-hackers

On 10/07/2023 15:37, Peter Eisentraut wrote:
> A few suggestions on the API:
> 
>   > +static ResourceOwnerFuncs tupdesc_resowner_funcs =
> 
> These aren't all "functions", so maybe another word like "info" or
> "description" would be more appropriate?
> 
> 
>   > +   .release_phase = RESOURCE_RELEASE_AFTER_LOCKS,
>   > +   .release_priority = RELEASE_PRIO_TUPDESC_REFS,
> 
> I suggest assigning explicit non-zero numbers to the RESOURCE_RELEASE_*
> constants, as well as changing RELEASE_PRIO_FIRST to 1 and adding an
> assertion that the priority is not zero.  Otherwise, someone might
> forget to assign these fields and would implicitly get phase 0 and
> priority 0, which would probably work in most cases, but wouldn't be the
> explicit intention.

Done.

> Then again, you are using RELEASE_PRIO_FIRST for the pgcrypto patch.  Is
> it the recommendation that if there are no other requirements, external
> users should use that?  If we are going to open this up to external
> users, we should probably have some documented guidance around this.

I added a brief comment about that in the ResourceReleasePhase typedef.

I also added a section to the README on how to define your own resource 
kind. (The README doesn't go into any detail on how to choose the 
release priority though).

>   > +   .PrintLeakWarning = ResOwnerPrintTupleDescLeakWarning
> 
> I think this can be refactored further.  We really just need a function
> to describe a resource, like maybe
> 
> static char *
> ResOwnerDescribeTupleDesc(Datum res)
> {
>       TupleDesc   tupdesc = (TupleDesc) DatumGetPointer(res);
> 
>       return psprintf("TupleDesc %p (%u,%d)",
>                       tupdesc, tupdesc->tdtypeid, tupdesc->tdtypmod);
> }
> 
> and then the common code can generate the warnings from that like
> 
>       elog(WARNING,
>            "%s leak: %s still referenced",
>            kind->name, kind->describe(value));
> 
> That way, we could more easily develop further options, such as turning
> this warning into an error (useful for TAP tests).
> 
> Also, maybe, you could supply a default description that just prints
> "%p", which appears to be applicable in about half the places.

Refactored it that way.

> Possible bonus project: I'm not sure these descriptions are so useful
> anyway.  It doesn't help me much in debugging if "File 55 was not
> released" or some such.  If would be cool if ResourceOwnerRemember() in
> some debug mode could remember the source code location, and then print
> that together with the leak warning.

Yeah, that would be useful. I remember I've hacked something like that 
as a one-off thing in the past, when debugging a leak.

>   > +#define ResourceOwnerRememberTupleDesc(owner, tupdesc) \
>   > +   ResourceOwnerRemember(owner, PointerGetDatum(tupdesc),
> &tupdesc_resowner_funcs)
>   > +#define ResourceOwnerForgetTupleDesc(owner, tupdesc) \
>   > +   ResourceOwnerForget(owner, PointerGetDatum(tupdesc),
> &tupdesc_resowner_funcs)
> 
> I would prefer that these kinds of things be made inline functions, so
> that we maintain the type safety of the previous interface.  And it's
> also easier when reading code to see type decorations.
> 
> (But I suspect the above bonus project would require these to be macros?)
> 
> 
>   > +   if (context->resowner)
>   > +       ResourceOwnerForgetJIT(context->resowner, context);
> 
> It seems most ResourceOwnerForget*() calls have this kind of check
> before them.  Could this be moved inside the function?

Many do, but I don't know if it's the majority. We could make 
ResurceOwnerForget(NULL) do nothing, but I think it's better to have the 
check in the callers. You wouldn't want to silently do nothing when the 
resource owner is not expected to be NULL.

(I'm attaching new patch version in my reply to Andres shortly)

-- 
Heikki Linnakangas
Neon (https://neon.tech)