On 04/06/2018 08:13 PM, Andres Freund wrote:
> On 2018-04-06 19:59:17 +0200, Tomas Vondra wrote:
>> On 04/06/2018 07:46 PM, Andres Freund wrote:
>>>> Sure. But what would that be? I can't think of anything. A process that
>>>> modifies a buffer (or any other piece of shared state) without holding
>>>> some sort of lock seems broken by default.
>>>
>>> You can quite possibly already *hold* a lock if it's not an exclusive
>>> one.
>>>
>>
>> Sure, but if you're holding the buffer lock when the checksum version is
>> changed, then the checksumhelper is obviously not running yet. In which
>> case it will update the checksum on the buffer later.
>
> The buffer content lock itself doesn't generally give any such guarantee
> afaict, as it's required that the content lock is held in shared mode
> during IO. ProcessSingleRelationFork() happens to use exclusive mode
> (which could and possibly should be optimized), so that's probably
> sufficient from that end though.
>
Oh, I've just realized the phrasing of my previous message was rather
confusing. What I meant to say is this:
Sure, but the checksum version is changed before the checksumhelper
launcher/worker is even started. So if you're holding the buffer lock
at that time, then the buffer is essentially guaranteed to be updated
by the worker later.
Sorry if it seemed I'm suggesting the buffer lock itself guarantees
something about the worker startup.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services