database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-08-25 20:23:07 +03:00
Code Activity

Convert many uses of ReadBuffer[Extended](P_NEW) to ExtendBufferedRel()

Browse Source 
A few places are not converted. Some because they are tackled in later
commits (e.g. hio.c, xlogutils.c), some because they are more
complicated (e.g. brin_pageops.c).  Having a few users of ReadBuffer(P_NEW) is
good anyway, to ensure the backward compat path stays working.

Discussion: https://postgr.es/m/20221029025420.eplyow6k7tgu6he3@awork3.anarazel.de
This commit is contained in:
Andres Freund
2023-04-05 18:57:29 -07:00
parent fcdda1e4b5
commit acab1b0914
13 changed files with 42 additions and 96 deletions
Download Patch File Download Diff File Expand all files Collapse all files

34
src/backend/access/nbtree/nbtpage.c
View File

@@ -882,7 +882,6 @@ _bt_getbuf(Relation rel, Relation heaprel, BlockNumber blkno, int access)
}
else
{
bool needLock;
Page page;
Assert(access == BT_WRITE);
@@ -963,31 +962,16 @@ _bt_getbuf(Relation rel, Relation heaprel, BlockNumber blkno, int access)
}
/*
* Extend the relation by one page.
*
* We have to use a lock to ensure no one else is extending the rel at
* the same time, else we will both try to initialize the same new
* page. We can skip locking for new or temp relations, however,
* since no one else could be accessing them.
* Extend the relation by one page. Need to use RBM_ZERO_AND_LOCK or
* we risk a race condition against btvacuumscan --- see comments
* therein. This forces us to repeat the valgrind request that
* _bt_lockbuf() otherwise would make, as we can't use _bt_lockbuf()
* without introducing a race.
*/
needLock = !RELATION_IS_LOCAL(rel);
if (needLock)
LockRelationForExtension(rel, ExclusiveLock);
buf = ReadBuffer(rel, P_NEW);
/* Acquire buffer lock on new page */
_bt_lockbuf(rel, buf, BT_WRITE);
/*
* Release the file-extension lock; it's now OK for someone else to
* extend the relation some more. Note that we cannot release this
* lock before we have buffer lock on the new page, or we risk a race
* condition against btvacuumscan --- see comments therein.
*/
if (needLock)
UnlockRelationForExtension(rel, ExclusiveLock);
buf = ExtendBufferedRel(EB_REL(rel), MAIN_FORKNUM, NULL,
EB_LOCK_FIRST);
if (!RelationUsesLocalBuffers(rel))
VALGRIND_MAKE_MEM_DEFINED(BufferGetPage(buf), BLCKSZ);
/* Initialize the new page before returning it */
page = BufferGetPage(buf);

3
src/backend/access/nbtree/nbtree.c
View File

@@ -970,6 +970,9 @@ btvacuumscan(IndexVacuumInfo *info, IndexBulkDeleteResult *stats,
* write-lock on the left page before it adds a right page, so we must
* already have processed any tuples due to be moved into such a page.
*
* XXX: Now that new pages are locked with RBM_ZERO_AND_LOCK, I don't
* think the use of the extension lock is still required.
*
* We can skip locking for new or temp relations, however, since no one
* else could be accessing them.
*/