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 по дате отправления: