Re: the s_lock_stuck on perform_spin_delay - Mailing list pgsql-hackers

From Andy Fan
Subject Re: the s_lock_stuck on perform_spin_delay
Date
Msg-id 87o7dum084.fsf@163.com
Whole thread Raw
In response to Re: the s_lock_stuck on perform_spin_delay  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: the s_lock_stuck on perform_spin_delay
List pgsql-hackers
Hi,

Robert Haas <robertmhaas@gmail.com> writes:

> On Mon, Jan 8, 2024 at 9:40 PM Andy Fan <zhihuifan1213@163.com> wrote:
>> The singler handler I was refering to is 'CHECK_FOR_INTERRUPTS', Based
>> on this, spin_lock and lwlock are acted pretty differently.
>
> CHECK_FOR_INTERRUPTS() is not a signal handler,

hmm, I knew this but .... I think we haven't big difference in mind
actually.

Since all of them agreed that we should do something in infrastructure
to detect some misuse of spin.  I want to know if Andres or you have plan
to do some code review. I don't expect this would happen very soon, just
want to make sure this will not happen that both of you think the other
one will do, but actually none of them does it in fact. a commit fest
[1] has been added for this.

There is a test code show the bad practice which is detected by this
patch in [2]

[1] https://commitfest.postgresql.org/47/4768/
[2] https://www.postgresql.org/message-id/87le91obp7.fsf%40163.com.
--
Best Regards
Andy Fan


Attachment

pgsql-hackers by date:

Previous
From: jian he
Date:
Subject: Re: [PATCH] Add sortsupport for range types and btree_gist
Next
From: Peter Smith
Date:
Subject: Re: Synchronizing slots from primary to standby