Re: generalized conveyor belt storage

On Wed, Dec 15, 2021 at 10:03 AM Matthias van de Meent
<boekewurm+postgres(at)gmail(dot)com> wrote:
> > +Conceptually, a relation fork organized as a conveyor belt has three parts:
> > +
> > +- Payload. The payload is whatever data the user of this module wishes
> > + to store. The conveyor belt doesn't care what you store in a payload page,
> > + but it does require that you store something: each time a payload page is
> > + initialized, it must end up with either pd_lower > SizeOfPageHeaderData,
> > + or pd_lower < BLCKSZ.
>
> As SizeOfPageHeaderData < BLCKSZ, isn't this condition always true? Or
> at least, this currently allows for either any value of pd_lower, or
> the (much clearer) 'pd_lower <= SizeOfPageHeaderData or pd_lower >=
> BLCKSZ', depending on exclusiveness of the either_or clause.

The second part of the condition should say pd_upper < BLCKSZ, not
pd_lower. Woops. It's intended to be false for uninitialized pages and
also for pages that are initialized but completely empty with no line
pointers and no special space.

> You mentioned that this is meant to be used as a "relation fork", but
> I couldn't find new code in relpath.h (where ForkNumber etc. are
> defined) that allows one more fork per relation. Is that too on the
> missing features list, or did I misunderstand what you meant with
> "relation fork"?

It's up to whoever is using the code to provide the relation fork -
and it could be the main fork of some new kind of relation, or it
could use some other existing fork number, or it could be an entirely
new fork. But it would be up to the calling code to figure that stuff
out.

--
Robert Haas
EDB: http://www.enterprisedb.com