| From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
|---|---|
| To: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
| Cc: | tsunakawa(dot)takay(at)fujitsu(dot)com, k(dot)jamison(at)fujitsu(dot)com, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andres Freund <andres(at)anarazel(dot)de>, Robert Haas <robertmhaas(at)gmail(dot)com>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: [Patch] Optimize dropping of relation buffers using dlist |
| Date: | 2020-10-22 09:27:00 |
| Message-ID: | CA+hUKGLxeLxXGG0RAEasZAh_QKzXPshV6i--dKcPtr6k5dCf0g@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Oct 22, 2020 at 9:50 PM Kyotaro Horiguchi
<horikyota(dot)ntt(at)gmail(dot)com> wrote:
> By the way, heap scan finds the size of target relation using
> smgrnblocks(). I'm not sure why we don't miss recently-extended pages
> on a heap-scan? It seems to be possible that concurrent checkpoint
> fsyncs relation files inbetween the extension and scanning and the
> scanning gets smaller size than it really is.
Yeah. That's a narrow window: fsync() returns an error after the file
shrinks and we immediately panic. A version with a wider window: the
kernel tries to write in the background, gets an I/O error, shrinks
the file, but we don't know this and we continue running until the
next checkpoint calls fsync(), sees the error and panics. Seq scans
between those two events fail to see recently committed data at the
end of the table.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | John Naylor | 2020-10-22 09:50:52 | Re: speed up unicode decomposition and recomposition |
| Previous Message | Kyotaro Horiguchi | 2020-10-22 09:16:48 | Re: Enumize logical replication message actions |