From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
Cc: | michael(at)paquier(dot)xyz, masao(dot)fujii(at)oss(dot)nttdata(dot)com, amit(dot)kapila16(at)gmail(dot)com, pasim(at)vmware(dot)com, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: elog(DEBUG2 in SpinLocked section. |
Date: | 2020-06-03 18:35:29 |
Message-ID: | 1142282.1591209329@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> writes:
> I looked through 224 locations where SpinLockAcquire and found some.
Yeah, I made a similar scan and arrived at about the same conclusions.
I think that the memcpy and strlcpy calls are fine; at least, we've got
to transport data somehow and it's not apparent why those aren't OK ways
to do it. The one use of StrNCpy is annoying from a cosmetic standpoint
(mainly because it's Not Like Anywhere Else) but I'm not sure it's worth
changing.
The condition-variable code has a boatload of spinlocked calls of the
proclist functions in proclist.h. All of those are straight-line code
so they're okay performance wise, but I wonder if we shouldn't add a
comment to that header pointing out that its functions must not throw
errors.
The only other thing I remain concerned about is some instances of atomic
operations inside spinlocks, which I started a separate thread about [1].
regards, tom lane
[1] https://www.postgresql.org/message-id/1141819.1591208385%40sss.pgh.pa.us
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2020-06-03 18:38:59 | Re: Parallel copy |
Previous Message | Tom Lane | 2020-06-03 18:25:07 | Re: question regarding copyData containers |