References: <87plyhvama.fsf@163.com>
 <CA+TgmoaA2uqsozTj9UDNrXTKWiUz1kW9eQsKiCr9ZvPwaFGFDA@mail.gmail.com>
 <20240104225403.dgmbbfffmm3srpgq@awork3.anarazel.de>
 <871qaso7ub.fsf@163.com>
 <CA+TgmoabLxQCbnatgdcO_VZKQtZqnj4c0zg3ovavqBZBh+QYcA@mail.gmail.com>
 <87sf37mdqq.fsf@163.com>
 <CA+TgmobMJLKnsR_pLnOmRdb7+AzCLdNPFOqG4TAatU1F_4gyaQ@mail.gmail.com>
 <87o7dum084.fsf@163.com>
 <CAEze2WggP-2Dhocmdhp-LxBzic=MXRgGA_tmv1G_9n-PDt2MQg@mail.gmail.com>
 <87h6jkmucz.fsf@163.com>
 <CA+TgmoYJoFsn3Mqhj0_0HNgVjtPfahJMgF2Pb7wzDcRFvZuK9w@mail.gmail.com>
 <8734uz17va.fsf@163.com> <87o7diyf3z.fsf@163.com>
 <CA+TgmoZNo2hedpnyhr3bMUZ+grzp1+2B4daG6O_NeJPh0QnhMA@mail.gmail.com>
 <87edeexznn.fsf@163.com>
 <CA+TgmobPBwwVmtth1e0mJYKyLnwN1v7d1OWJ2toiwFrnFAOo-w@mail.gmail.com>
 <87a5p2xc2v.fsf@163.com> <871qadygzz.fsf@163.com> <87wms2w9hn.fsf@163.com>
 <87o7ddx26q.fsf@163.com>
 <CA+TgmoaaMow6F3He-ScxqAP3vej2P1=HWj_ijBSyVYmyKwfF=g@mail.gmail.com>
User-agent: mu4e 1.10.7; emacs 29.1
From: Andy Fan <zhihuifan1213@163.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Matthias van de Meent <boekewurm+postgres@gmail.com>, Andres Freund
 <andres@anarazel.de>, Tom Lane <tgl@sss.pgh.pa.us>, Thomas Munro
 <tmunro@postgresql.org>, pgsql-hackers@lists.postgresql.org
Subject: Re: the s_lock_stuck on perform_spin_delay
Date: Tue, 23 Jan 2024 00:16:10 +0800
In-reply-to: 
 <CA+TgmoaaMow6F3He-ScxqAP3vej2P1=HWj_ijBSyVYmyKwfF=g@mail.gmail.com>
Message-ID: <87cyttwbin.fsf@163.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/87cyttwbin.fsf%40163.com>
Precedence: bulk


Robert Haas <robertmhaas@gmail.com> writes:

> On Mon, Jan 22, 2024 at 2:22=E2=80=AFAM Andy Fan <zhihuifan1213@163.com> =
wrote:
>> I used sigismember(&BlockSig, SIGQUIT) to detect if a process is doing a
>> quickdie, however this is bad not only because it doesn't work on
>> Windows, but also it has too poor performance even it impacts on
>> USE_ASSERT_CHECKING build only. In v8, I introduced a new global
>> variable quickDieInProgress to handle this.
>
> OK, I like the split between 0001 and 0002. I still think 0001 has
> cosmetic problems, but if some committer wants to take it forward,
> they can decide what to do about that; you and I going back and forth
> doesn't seem like the right approach to sorting that out. Whether or
> not 0002 is adopted might affect what we do about the cosmetics in
> 0001, too.

Replacing ASSERT_NO_SPIN_LOCK with VerifyNoSpinLocksHeld or adding more
comments to each call of VerifyNoSpinLocksHeld really makes me happy
since they make things more cosmetic and practical. So I'd be absolutely
willing to do more stuff like this. Thanks for such suggestions!

Then I can't understand the left cosmetic problems... since you are
saying it may related to 0002, I guess you are talking about the naming
of START_SPIN_LOCK and END_SPIN_LOCK?

>
> 0003 seems ... unfortunate. It seems like an admission that 0001 is
> wrong.

Yes, that's what I was thinking. I doubted if I should merge 0003 to
0001 directly during this discussion, and finally I made it separate for
easier dicussion.

> Surely it *isn't* right to ignore the spinlock restrictions in
> quickdie() in general. For example, we could self-deadlock if we try
> to acquire a spinlock we already hold. If the problem here is merely
> the call in errstart() then maybe we need to rethink that particular
> call. If it goes any deeper than that, maybe we've got actual bugs we
> need to fix.

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. Since the problem here is just
errstart, we can do a if(!quickDieInProgress) VerifyNoSpinLocksHeld();
in errstart only. Another place besides the errstart is the
CHECK_FOR_INTERRUPTS in errfinish. I think we can add the same check for
the VerifyNoSpinLocksHeld in CHECK_FOR_INTERRUPTS.

>
> +        * It's likely to check the BlockSig to know if it is doing a qui=
ckdie
> +        * with sigismember, but it is too expensive in test, so introduce
> +        * quickDieInProgress to avoid that.
>
> This isn't very good English -- I realize that can sometimes be hard
> -- but also -- I don't think it likely that a future hacker would
> wonder why this isn't done that way. A static variable is normal for
> PostgreSQL; checking the signal mask would be a completely novel
> approach. So I think this comment is missing the mark topically.

I was wrong to think sigismember is a syscall, but now I see it is just
a function in glibc. Even I can't get the source code of it, I think it
should just be some bit-operation based on the definition of __sigset_t.=20

Another badness of sigismember is it is not avaiable in windows. It is
still unclear to me why sigaddset in quickdie can=20
compile in windows.  (I have a sigismember version and get a linker
error at windows). This should be a blocker for me to submit the next
version of patch.

> If
> this patch is right at all, the comment here should focus on why
> disabling these checks in quickdie() is necessary and appropriate, not
> why it's coded to match everything else in the system.

I agree, and I think the patch 0003 is not right at all:(

--=20
Best Regards
Andy Fan