Re: logtape.c stats don't account for unused "prefetched" block numbers
Jeff Davis <pgsql@j-davis.com>
From: Jeff Davis <pgsql@j-davis.com>
To: Peter Geoghegan <pg@bowt.ie>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2020-09-15T03:07:44Z
Lists: pgsql-hackers
On Mon, 2020-09-14 at 19:29 -0700, Peter Geoghegan wrote: > Let's assume that we'll teach LogicalTapeSetBlocks() to use > nBlocksWritten in place of nBlocksAllocated in all cases, as now > seems > likely. Rather than asserting "nBlocksWritten == nBlocksAllocated" > inside LogicalTapeSetBlocks() (as I suggested earlier at one point), > we could instead teach LogicalTapeSetBlocks() to iterate through each > tape from the tapeset and make sure each tape has no writes buffered > (so everything must be flushed). We could add a loop that would only > be used on assert-enabled builds. Sounds reasonable. > You suggested this yourself, Jeff (my suggestion about the assertion > is just an expansion on your suggestion from earlier). This all seems > like a good idea to me. Can you write a patch that adjusts > LogicalTapeSetBlocks() along these lines? Hopefully the assertion > loop > thing won't reveal some other problem with this plan. Sure. Will backporting either patch into REL_13_STABLE now interfere with RC1 release in any way? Regards, Jeff Davis
Commits
-
Change LogicalTapeSetBlocks() to use nBlocksWritten.
- 6e146a663536 13.0 landed
- c8aeaf3ab31e 14.0 landed
-
HashAgg: release write buffers sooner by rewinding tape.
- 42a46f5a76ec 13.0 landed
- 3bd35d4f516a 14.0 landed
-
logtape.c: do not preallocate for tapes when sorting
- 93106d71a18a 13.0 landed
- 075896496394 14.0 landed
-
Fix bogus MaxAllocSize check in logtape.c.
- 4a4f3bf983b4 13.0 landed
- 0852006a946a 14.0 landed
-
Avoid fragmentation of logical tapes when writing concurrently.
- 896ddf9b3cd7 13.0 cited
-
Logical Tape Set: use min heap for freelist.
- c02fdc922301 13.0 cited
-
Don't create "holes" in BufFiles, in the new logtape code.
- 7ac4a389a7db 10.0 cited