Hi,
> On 2024-01-05 14:19:23 -0500, Robert Haas wrote:
>> On Fri, Jan 5, 2024 at 2:11 PM Andres Freund <andres@anarazel.de> wrote:
>> > I see it fairly regularly. Including finding several related bugs that lead to
>> > stuck systems last year (signal handlers are a menace).
>>
>> In that case, I think this proposal is dead. I can't personally
>> testify to this code being a force for good, but it sounds like you
>> can. So be it!
>
> I think the proposal to make it a WARNING shouldn't go anywhere,
OK, I give up the WARNING method as well.
> but I think
> there are several improvements that could come out of this discussion:
>
> - assertion checks against doing dangerous stuff
> - make the stuck lock message more informative, e.g. by including the length
> of time the lock was stuck for
Could you check the attached to see if it is something similar in your
mind?
commit e264da3050285cffd4885637ee97b2326d2f3938 SHOULD **NOT** BE COMMITTED.
Author: yizhi.fzh <yizhi.fzh@alibaba-inc.com>
Date: Sun Jan 7 15:06:14 2024 +0800
simple code to prove previously commit works.
commit 80cf987d1abe2cdae195bd5eea520e28142885b4
Author: yizhi.fzh <yizhi.fzh@alibaba-inc.com>
Date: Thu Jan 4 22:19:50 2024 +0800
Detect more misuse of spin lock automatically
spin lock are intended for *very* short-term locks, but it is possible
to be misused in many cases. e.g. Acquiring another LWLocks or regular
locks, memory allocation. In this patch, all of such cases will be
automatically detected in an ASSERT_CHECKING build.
Signal handle should be avoided when holding a spin lock because it is
nearly impossible to release the spin lock correctly if that happens.
Luckly after applying the patch, there is no failure when run 'make
check-world'.
> - make sure that interrupts can't trigger the stuck lock much quicker, which
> afaict can happen today
I can't follow this, do you mind explain more about this a bit?
--
Best Regards
Andy Fan