Re: subscriptionCheck failures on nightjar

On 9/20/19 6:17 PM, Tom Lane wrote:
> Alvaro Herrera <alvherre@2ndquadrant.com> writes:
>> Uh .. I didn't think it was possible that we would build the same
>> snapshot file more than once.  Isn't that a waste of time anyway?  Maybe
>> we can fix the symptom by just not doing that in the first place?
>> I don't have a strategy to do that, but seems worth considering before
>> retiring the bf animals.
> The comment near the head of SnapBuildSerialize says
>
>      * there is an obvious race condition here between the time we stat(2) the
>      * file and us writing the file. But we rename the file into place
>      * atomically and all files created need to contain the same data anyway,
>      * so this is perfectly fine, although a bit of a resource waste. Locking
>      * seems like pointless complication.
>
> which seems like a reasonable argument.  Also, this is hardly the only
> place where we expect rename(2) to be atomic.  So I tend to agree with
> Andres that we should consider OSes with such a bug to be unsupported.
>
> Dromedary is running the last release of macOS that supports 32-bit
> hardware, so if we decide to kick that to the curb, I'd either shut
> down the box or put some newer Linux or BSD variant on it.
>
>             



Well, nightjar is on FBSD 9.0 which is oldish. I can replace it before
long with an 11-stable instance if that's appropriate.


cheers


andrew

-- 
Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services