pgsql: Remove UpdateFreeSpaceMap(), use FreeSpaceMapVacuumRange() inste

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-committers(at)lists(dot)postgresql(dot)org
Subject: pgsql: Remove UpdateFreeSpaceMap(), use FreeSpaceMapVacuumRange() inste
Date: 2018-03-29 16:22:54
Message-ID: E1f1aKE-0002WH-P2@gemulon.postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers

Remove UpdateFreeSpaceMap(), use FreeSpaceMapVacuumRange() instead.

FreeSpaceMapVacuumRange has the same effect, is more efficient if many
pages are involved, and makes fewer assumptions about how it's used.
Notably, Claudio Freire pointed out that UpdateFreeSpaceMap could fail
if the specified freespace value isn't the maximum possible. This isn't
a problem for the single existing user, but the function represents an
attractive nuisance IMO, because it's named as though it were a
general-purpose update function and its limitations are undocumented.
In any case we don't need multiple ways to get the same result.

In passing, do some code review and cleanup in RelationAddExtraBlocks.
In particular, I see no excuse for it to omit the PageIsNew safety check
that's done in the mainline extension path in RelationGetBufferForTuple.

Discussion: https://postgr.es/m/CAGTBQpYR0uJCNTt3M5GOzBRHo+-GccNO1nCaQ8yEJmZKSW5q1A@mail.gmail.com

Branch
------
master

Details
-------
https://git.postgresql.org/pg/commitdiff/a063baaced273e955e088ba5979dcc6ec5cd92e6

Modified Files
--------------
src/backend/access/heap/hio.c | 44 +++++++++++------
src/backend/storage/freespace/freespace.c | 81 -------------------------------
src/include/storage/freespace.h | 4 --
3 files changed, 30 insertions(+), 99 deletions(-)

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2018-03-29 16:44:24 pgsql: Remove unnecessary BufferGetPage() calls in fsm_vacuum_page().
Previous Message Bruce Momjian 2018-03-29 16:18:44 pgsql: C comment: fix wording about shared memory message queue