Re: subscriptionCheck failures on nightjar

On 9/20/19 6:17 PM, Tom Lane wrote:
> Alvaro Herrera <alvherre(at)2ndquadrant(dot)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