| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, "tgl(at)sss(dot)pgh(dot)pa(dot)us" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "robertmhaas(at)gmail(dot)com" <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Temporary tables prevent autovacuum, leading to XID wraparound |
| Date: | 2018-08-08 19:11:17 |
| Message-ID: | 20180808191117.GC13638@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2018-08-08 19:14:50 | Re: REINDEX and shared catalogs |
| Previous Message | Simon Muller | 2018-08-08 18:57:33 | Re: Allow COPY's 'text' format to output a header |