Re: subscriptionCheck failures on nightjar - Mailing list pgsql-hackers

From Tom Lane
Subject Re: subscriptionCheck failures on nightjar
Date
Msg-id 4218.1569017822@sss.pgh.pa.us
Whole thread Raw
In response to Re: subscriptionCheck failures on nightjar  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: subscriptionCheck failures on nightjar
List pgsql-hackers
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.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: WAL recycled despite logical replication slot
Next
From: Andres Freund
Date:
Subject: Re: WIP: Generic functions for Node types using generated metadata