2025년 3월 14일 (금) 오후 11:36, Nathan Bossart <nathandboss...@gmail.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
