From: | Sungwoo Chang <swchangdev(at)gmail(dot)com> |
---|---|
To: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: dsm_registry: Add detach and destroy features |
Date: | 2025-03-16 23:54:23 |
Message-ID: | CAAdDe3PqXvDyNQTEyskvecw-Gu-27xr81wM-jc157i95pN+3NQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Tatsuo Ishii | 2025-03-17 00:17:42 | git web interface broken? |
Previous Message | Michael Paquier | 2025-03-16 23:39:49 | Re: Dubious server log messages after pg_upgrade |