Message-ID: <55e6a615-ec9d-4a57-8f36-7fbd1674da2c@postgrespro.ru>
Date: Fri, 11 Sep 2026 17:43:22 +0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: convert various variables to atomics
To: pgsql-hackers@lists.postgresql.org
References: <alAJeRRzehDjLaF1@nathan>
 <9d8c317d-d933-46c7-b675-4b9308eaca2b@eisentraut.org>
 <amDAZAVob4DJjUfW@nathan>
 <ycvruij7554tlhw6w7bg4lqtibd52qguo52iojyou7ejdv5jrm@qyyr5f3hdsue>
 <amDGRZxnlmTVjkCe@nathan> <amJx4Lwx4nuuExYT@nathan>
 <207c0bfb-6e06-4358-bb2f-c961915efc36@eisentraut.org>
 <hi4rsxwu3ioas5rmuwfnu2gisqb2rd6g2uq56r3pvzk7clismo@oyndzrrylnir>
 <3856d1cf-53a8-414b-98d9-829d5a455a86@iki.fi> <aqA_P7Uwub-MDXOO@nathan>
 <aqBmuOO26ZtG_BgX@nathan>
Content-Language: en-US
From: Yura Sokolov <y.sokolov@postgrespro.ru>
In-Reply-To: <aqBmuOO26ZtG_BgX@nathan>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Archived-At: 
 <https://www.postgresql.org/message-id/55e6a615-ec9d-4a57-8f36-7fbd1674da2c%40postgrespro.ru>
Precedence: bulk

08.09.2026 22:49, Nathan Bossart пишет:
> On Tue, Sep 08, 2026 at 12:00:47PM -0500, Nathan Bossart wrote:
>> * v2-0001: We are changing a variable from signed to unsigned, but the code
>> goes out of its way to avoid negative values and signed integer overflow,
>> so I don't think there are any real problems here.  The only atomic
>> arithmetic operation is in SICleanupQueue() where we subtract
>> MSGNUMWRAPAROUND, which IIUC should never produce a negative value.  That
>> being said, I don't think it would be too disruptive to switch all relevant
>> variables to uint32 as a prerequisite patch.  I don't see any particular
>> reason for those variables to be signed, anyway.
> 
> v3-0001 is the prerequisite patch.  This requires some new clamping logic
> in SICleanupQueue() for minsig and lowbound, since the subtractions can
> produce negative values.  I believe this retains the existing behavior, but
> need to double-check.

Personally, I don't like current implementation of
pg_atomic_read_membarrier_u32 because it writes into shared variable.

That is why in [1] (thread [2]) I used explicit pg_memory_barrier before
and pg_read_barrier after reading segP->maxMsgNum. (pg_memory_barrier
writes onto stack - process's private memory, and pg_read_barrier does
nothing on x86_64).

[1]
https://www.postgresql.org/message-id/attachment/174633/v3-0001-sinvaladt.c-use-atomic-operations-on-maxMsgNum.patch
[2]
https://www.postgresql.org/message-id/flat/30aa0030-f694-44ef-a19d-6ef7ddb69374%40postgrespro.ru

-- 
regards
Yura Sokolov aka funny-falcon