On 2026-Jun-02, Mingwei Jia wrote:
> diff --git a/src/backend/storage/map/map.c b/src/backend/storage/map/map.c
> new file mode 100644
> index 0000000000..563f38b21a
> --- /dev/null
> +++ b/src/backend/storage/map/map.c
> @@ -0,0 +1,162 @@
> +/*-------------------------------------------------------------------------
> + *
> + * map.c
> + * Umbra metadata-fork disk layout helpers.
> + *
> + * This file contains address-translation and in-page access routines for the
> + * metadata fork disk layout.
> + *
> + * src/backend/storage/map/map.c
> + *
> + *-------------------------------------------------------------------------
> + */
I find this pretty difficult to understand, and I think it's because the
fork system is the wrong abstraction. The current system is too
obviously centered around heapam and nbtree, to the detriment of
everything else. I would like a system whereby each (index, table) AM
can determine which forks exist and how to deal with each. For
instance, BRIN indexes have a "revmap" at the start of the main fork;
when it needs one more "revmap" page but it's already used by regular
index tuples, it needs to move all those existing index tuples to
another page so that the page can be used as a revmap page (I think this
is called "evacuate"). That's absurd and overcomplicated. If the
revmap had its own fork, a bunch of code and locking considerations
would go simply away.
I think that would also apply to this map thingy you want to create
(although I can't claim to have really understood what you're trying to
achieve).
Anyway, if I'm pointing in roughly the right direction, then I don't
like the idea of this new smgr creating yet another layer to paper over
that failed abstraction. Let's fix that instead.
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
