Re: ERROR: invalid spinlock number: 0 - Mailing list pgsql-hackers

From Fujii Masao
Subject Re: ERROR: invalid spinlock number: 0
Date
Msg-id 918a47fc-e1fa-0c99-15e3-59b520455fe0@oss.nttdata.com
Whole thread Raw
In response to Re: ERROR: invalid spinlock number: 0  (Andres Freund <andres@anarazel.de>)
Responses Re: ERROR: invalid spinlock number: 0
List pgsql-hackers

On 2021/02/16 6:28, Andres Freund wrote:
> Hi,
> 
> On 2021-02-15 19:45:21 +0900, Michael Paquier wrote:
>> On Mon, Feb 15, 2021 at 10:47:05PM +1300, Thomas Munro wrote:
>>> Why not initialise it in WalRcvShmemInit()?
>>
>> I was thinking about doing that as well, but we have no real need to
>> initialize this stuff in most cases, say standalone deployments.  In
>> particular for the fallback implementation of atomics, we would
>> prepare a spinlock for nothing.
> 
> So what? It's just about free to initialize a spinlock, whether it's
> using the fallback implementation or not. Initializing upon walsender
> startup adds a lot of complications, because e.g. somebody could already
> hold the spinlock because the previous walsender just disconnected, and
> they were looking at the stats.

Even if we initialize "writtenUpto" in WalRcvShmemInit(), WalReceiverMain()
still needs to initialize (reset to 0) by using pg_atomic_write_u64().

Basically we should not acquire new spinlock while holding another spinlock,
to shorten the spinlock duration. Right? If yes, we need to move
pg_atomic_read_u64() of "writtenUpto" after the release of spinlock in
pg_stat_get_wal_receiver.

Attached is the updated version of the patch.

Regards,

-- 
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION

Attachment

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: logical replication seems broken
Next
From: David Rowley
Date:
Subject: Re: Keep notnullattrs in RelOptInfo (Was part of UniqueKey patch series)