diff options
author | Andres Freund <andres@anarazel.de> | 2019-01-28 17:16:56 -0800 |
---|---|---|
committer | Andres Freund <andres@anarazel.de> | 2019-01-28 17:16:56 -0800 |
commit | 684200543b4cbfe1ac002c9962e90683d4ea4691 (patch) | |
tree | 988c5842339b4bbcd3494bf3e0873c2decde89dd /src/backend/access/heap/hio.c | |
parent | fc02e6724f3ce069b33284bce092052ab55bd751 (diff) | |
download | postgresql-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.c | 31 |
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) { |