Re: the s_lock_stuck on perform_spin_delay
От | Andy Fan |
---|---|
Тема | Re: the s_lock_stuck on perform_spin_delay |
Дата | |
Msg-id | 874jf5w9wa.fsf@163.com обсуждение исходный текст |
Ответ на | Re: the s_lock_stuck on perform_spin_delay (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> writes: > On Mon, Jan 22, 2024 at 12:13 PM Andy Fan <zhihuifan1213@163.com> wrote: >> > On Mon, Jan 22, 2024 at 11:58 AM Andy Fan <zhihuifan1213@163.com> wrote: >> >> I get your point! Acquiring an already held spinlock in quickdie is >> >> unlikely to happen, but since our existing infrastructure can handle it, >> >> then there is no reason to bypass it. >> > >> > No, the existing infrastructure cannot handle that at all. >> >> Actually I mean we can handle it without 0003. am I still wrong? >> Without the 0003, if we acquiring the spin lock which is held by >> ourself already. VerifyNoSpinLocksHeld in SpinLockAcquire should catch >> it. > > But that's only going to run in assert-only builds. The whole point of > the patch set is to tell developers that there are bugs in the code > that need fixing, not to catch problems that actually occur in > production. I see. As to this aspect, then yes. -- Best Regards Andy Fan
В списке pgsql-hackers по дате отправления: