Re: Temporary tables prevent autovacuum, leading to XID wraparound

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Temporary tables prevent autovacuum, leading to XID wraparound
Дата
Msg-id 67B75D8F-B6D2-4FC0-AD0B-0AF8CB99E10F@anarazel.de
обсуждение исходный текст
Ответ на Re: Temporary tables prevent autovacuum, leading to XID wraparound  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: Temporary tables prevent autovacuum, leading to XID wraparound
Список pgsql-hackers

On August 9, 2018 12:41:17 AM GMT+05:30, Michael Paquier <michael@paquier.xyz> wrote:
>Hi Andres,
>
>(Not my intention to miss your message, I have just noticed it.)
>
>On Wed, Aug 08, 2018 at 01:41:27AM -0700, Andres Freund wrote:
>> I can't parse this. "Even if this is an atomic operation, this can be
>> safely done lock-less" - that seems like a contradictory sentence. Is
>> there a "not" missing?
>
>Yes, a "not" has gone missing here.  I reworked the comment block as
>mentioned upthread.
>
>> Also, this seems like insufficient reasoning. What guarantees the
>> visibility of the flag? You're going to have to talk about externally
>> implied memory ordering here.  Or add explicit barriers - the latter
>is
>> probably preferrable.
>
>Well, we use BackendIdGetProc() in this case, where we could finish
>with
>information out-of-date pretty quickly, and there is no special
>reasoning for backendId and databaseId for autovacuum but...  Perhaps
>you could explain more what you have in mind?  And it is not like this
>relies on the number of elements in PGPROC.

My point is that the documentation isn't sufficient. Not that there's an active problem.

Andres

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: buildfarm: could not read block 3 in file "base/16384/2662": read only 0 of 8192 bytes
Следующее
От: Tom Lane
Дата:
Сообщение: Re: FailedAssertion on partprune