Re: the s_lock_stuck on perform_spin_delay

Поиск
Список
Период
Сортировка
От Andy Fan
Тема Re: the s_lock_stuck on perform_spin_delay
Дата
Msg-id 87o7dum084.fsf@163.com
обсуждение исходный текст
Ответ на Re: the s_lock_stuck on perform_spin_delay  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: the s_lock_stuck on perform_spin_delay  (Matthias van de Meent <boekewurm+postgres@gmail.com>)
Список 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


Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: jian he
Дата:
Сообщение: Re: [PATCH] Add sortsupport for range types and btree_gist
Следующее
От: Peter Smith
Дата:
Сообщение: Re: Synchronizing slots from primary to standby