Re: subscriptionCheck failures on nightjar

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: subscriptionCheck failures on nightjar
Дата
Msg-id 4218.1569017822@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: subscriptionCheck failures on nightjar  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Ответы Re: subscriptionCheck failures on nightjar  (Andrew Dunstan <andrew.dunstan@2ndquadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: WAL recycled despite logical replication slot
Следующее
От: Andres Freund
Дата:
Сообщение: Re: WIP: Generic functions for Node types using generated metadata