aboutsummaryrefslogtreecommitdiff
path: root/src/backend/access/heap/hio.c
diff options
context:
space:
mode:
authorAndres Freund <andres@anarazel.de>2019-01-28 17:16:56 -0800
committerAndres Freund <andres@anarazel.de>2019-01-28 17:16:56 -0800
commit684200543b4cbfe1ac002c9962e90683d4ea4691 (patch)
tree988c5842339b4bbcd3494bf3e0873c2decde89dd /src/backend/access/heap/hio.c
parentfc02e6724f3ce069b33284bce092052ab55bd751 (diff)
downloadpostgresql-684200543b4cbfe1ac002c9962e90683d4ea4691.tar.gz
postgresql-684200543b4cbfe1ac002c9962e90683d4ea4691.zip
Revert "Move page initialization from RelationAddExtraBlocks() to use."
This reverts commit fc02e6724f3ce069b33284bce092052ab55bd751 and e6799d5a53011985d916fdb48fe014a4ae70422e. Parts of the buildfarm error out with ERROR: page %u of relation "%s" should be empty but is not errors, and so far I/we do not know why. fc02e672 didn't fix the issue. As I cannot reproduce the issue locally, it seems best to get the buildfarm green again, and reproduce the issue without time pressure.
Diffstat (limited to 'src/backend/access/heap/hio.c')
-rw-r--r--src/backend/access/heap/hio.c31
1 files changed, 10 insertions, 21 deletions
diff --git a/src/backend/access/heap/hio.c b/src/backend/access/heap/hio.c
index 985c4c47779..3da0b49ccc4 100644
--- a/src/backend/access/heap/hio.c
+++ b/src/backend/access/heap/hio.c
@@ -204,8 +204,7 @@ RelationAddExtraBlocks(Relation relation, BulkInsertState bistate)
/*
* Extend by one page. This should generally match the main-line
* extension code in RelationGetBufferForTuple, except that we hold
- * the relation extension lock throughout, and we don't immediately
- * initialize the page (see below).
+ * the relation extension lock throughout.
*/
buffer = ReadBufferBI(relation, P_NEW, bistate);
@@ -217,16 +216,18 @@ RelationAddExtraBlocks(Relation relation, BulkInsertState bistate)
BufferGetBlockNumber(buffer),
RelationGetRelationName(relation));
+ PageInit(page, BufferGetPageSize(buffer), 0);
+
/*
- * Add the page to the FSM without initializing. If we were to
- * initialize here the page would potentially get flushed out to disk
- * before we add any useful content. There's no guarantee that that'd
- * happen before a potential crash, so we need to deal with
- * uninitialized pages anyway, thus avoid the potential for
- * unnecessary writes.
+ * We mark all the new buffers dirty, but do nothing to write them
+ * out; they'll probably get used soon, and even if they are not, a
+ * crash will leave an okay all-zeroes page on disk.
*/
+ MarkBufferDirty(buffer);
+
+ /* we'll need this info below */
blockNum = BufferGetBlockNumber(buffer);
- freespace = BufferGetPageSize(buffer) - SizeOfPageHeaderData;
+ freespace = PageGetHeapFreeSpace(page);
UnlockReleaseBuffer(buffer);
@@ -478,18 +479,6 @@ loop:
* we're done.
*/
page = BufferGetPage(buffer);
-
- /*
- * Initialize page, it'll be used soon. We could avoid dirtying the
- * buffer here, and rely on the caller to do so whenever it puts a
- * tuple onto the page, but there seems not much benefit in doing so.
- */
- if (PageIsNew(page))
- {
- PageInit(page, BufferGetPageSize(buffer), 0);
- MarkBufferDirty(buffer);
- }
-
pageFreeSpace = PageGetHeapFreeSpace(page);
if (len + saveFreeSpace <= pageFreeSpace)
{