Re: dsm_registry: Add detach and destroy features

2025년 3월 14일 (금) 오후 11:36, Nathan Bossart <nathandbossart(at)gmail(dot)com>님이 작성:
> My expectation is that the error handling takes care of these things. Are
> there cases where it does not? In any case, I would expect these errors to
> be extremely rare to the point of virtually never happening in practice.

I don't see any logic in ereport where it switches back the original
memory context.
I guess not switching back to the original memory context is not so
problematic because
we set it to TopMemoryContext and throw will cause the user to restart a query.
Not releasing the dshash lock could be problematic, so it's better to keep that.

You are right about these errors to be rare, especially the one where
we can't find a
dsm_segment given the dsm handle. However, user faults can cause the
other error,
where the input name and size for dshash lookup don't match.

> I'm delighted that folks want to expand on this feature, and I'm very
> interested in helping. Other things folks have asked for are a view into
> the DSM registry [0] and a simple way to allocate a DSA or dshash table
> with the DSM registry, all of which seem like good improvements to me.

I didn't know about the discussions on the view for DSM registry. I'm
happy to work on that.
I think what I can also add along with the view is the user command
for detaching/destroying
the dsm segment (like pg_backend_terminate function).

> That being said, we are at the very end of the v18 development cycle, and
> most folks are probably busy trying to finish their ongoing projects. So
> it may be a while before anyone can give this a meaningful review. Please
> be sure to add a commitfest entry [1] so it doesn't get lost.
>
> [0] https://postgr.es/m/4D445D3E-81C5-4135-95BB-D414204A0AB4%40gmail.com
> [1] https://commitfest.postgresql.org/

Thanks for the heads up. I will add an entry to the commitfest as you advised.

Best regards,

Sungwoo Chang