From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: ERROR: invalid spinlock number: 0 |
Date: | 2021-02-15 08:27:21 |
Message-ID: | YCowabyl1dwan+JP@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Feb 11, 2021 at 11:30:13PM +0900, Fujii Masao wrote:
> Yes, so what about the attached patch?
I see. So the first error triggering the spinlock error would cause
a transaction failure because the fallback implementation of atomics
uses a spinlock for this variable, and it may not initialized in this
code path.
> We didn't notice this issue long time because no regression test checks
> pg_stat_wal_receiver. So I included such test in the patch.
Moving that behind ready_to_display is fine by me seeing where the
initialization is done. The test case is a good addition.
+ * Read "writtenUpto" without holding a spinlock. So it may not be
+ * consistent with other WAL receiver's shared variables protected by a
+ * spinlock. This is OK because that variable is used only for
+ * informational purpose and should not be used for data integrity checks.
It seems to me that the first two sentences of this comment should be
combined together.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Langote | 2021-02-15 08:31:11 | Re: [POC] Fast COPY FROM command for the table with foreign partitions |
Previous Message | Joel Jacobson | 2021-02-15 08:21:21 | Re: Some regular-expression performance hacking |