Re: Temporary tables prevent autovacuum, leading to XID wraparound

On August 9, 2018 12:41:17 AM GMT+05:30, Michael Paquier <michael(at)paquier(dot)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.