Re: [Patch] Optimize dropping of relation buffers using dlist
Kyotaro Horiguchi <horikyota.ntt@gmail.com>
From: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
To: amit.kapila16@gmail.com
Cc: k.jamison@fujitsu.com, tsunakawa.takay@fujitsu.com, andres@anarazel.de,
tgl@sss.pgh.pa.us, thomas.munro@gmail.com, robertmhaas@gmail.com,
tomas.vondra@2ndquadrant.com, pgsql-hackers@postgresql.org
Date: 2020-12-08T00:53:14Z
Lists: pgsql-hackers
At Tue, 08 Dec 2020 09:45:53 +0900 (JST), Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote in > At Mon, 7 Dec 2020 17:18:31 +0530, Amit Kapila <amit.kapila16@gmail.com> wrote in > > Hmm, how is it possible if Insert is done before Truncate? The insert > > should happen in old RelFileNode only. I have verified by adding a > > break-in (while (1), so that it stops there) heap_xlog_insert and > > DropRelFileNodesAllBuffers(), and both get the same (old) RelFileNode. > > How have you verified what you are saying? > > You might be thinking of in-transaction sequence of > Inert-truncate. What *I* mention before is truncation of a relation > that smgrnblocks() has already been called for. The most common way > to make it happen was INSERTs *before* the truncating transaction > starts. It may be a SELECT on a hot-standby. Sorry for the confusing > expression. And ,to make sure, it is a bit off from the point of the discussion as I noted. I just meant that the proposition that "smgrnblokcs() always returns false for "cached" when it is called in DropRelFileNodesAllBuffers()" doesn't always holds. regards. -- Kyotaro Horiguchi NTT Open Source Software Center
Commits
-
Fix size overflow in calculation introduced by commits d6ad34f3 and bea449c6.
- 519e4c9ee21a 14.0 landed
-
Optimize DropRelFileNodesAllBuffers() for recovery.
- bea449c635c0 14.0 landed
-
Optimize DropRelFileNodeBuffers() for recovery.
- d6ad34f3410f 14.0 landed
-
Cache smgrnblocks() results in recovery.
- c5315f4f4484 14.0 cited
-
Add a check to prevent overwriting valid data if smgrnblocks() gives a
- ffae5cc5a602 8.2.0 cited