From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Amul Sul <sulamul(at)gmail(dot)com> |
Cc: | Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: generalized conveyor belt storage |
Date: | 2022-01-04 19:42:44 |
Message-ID: | CA+Tgmoa3S29wAayTHZSBJvvyWCrZhpJeQnft6ewv9htmcCYoDA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Dec 29, 2021 at 7:08 AM Amul Sul <sulamul(at)gmail(dot)com> wrote:
> Thought patch is WIP, here are a few comments that I found while
> reading the patch and thought might help:
>
> + {
> + if (meta->cbm_oldest_index_segment ==
> + meta->cbm_newest_index_segment)
> + elog(ERROR, "must remove last index segment when only one remains");
> + meta->cbm_oldest_index_segment = segno;
> + }
>
> How about having to assert or elog to ensure that 'segno' is indeed
> the successor?
This code doesn't have any inexpensive way to know whether segno is
the successor. To figure that out you'd need to look at the latest
index page that does exist, but this function's job is just to look at
the metapage. Besides, the eventual caller will have just looked up
that value in order to pass it to this function, so double-checking
what we just computed right before doesn't really make sense.
> + if (meta->cbm_index[offset] != offset)
> + elog(ERROR,
> + "index entry at offset %u was expected to be %u but found %u",
> + offset, segno, meta->cbm_index[offset]);
>
> IF condition should be : meta->cbm_index[offset] != segno ?
Oops, you're right.
> + if (segno >= CB_METAPAGE_FREESPACE_BYTES * BITS_PER_BYTE)
> + elog(ERROR, "segment %u out of range for metapage fsm", segno);
>
> I think CB_FSM_SEGMENTS_FOR_METAPAGE should be used like
> cb_metapage_set_fsm_bit()
Good call.
> +/*
> + * Increment the count of segments allocated.
> + */
> +void
> +cb_metapage_increment_next_segment(CBMetapageData *meta, CBSegNo segno)
> +{
> + if (segno != meta->cbm_next_segment)
> + elog(ERROR, "extending to create segment %u but next segment is %u",
> + segno, meta->cbm_next_segment);
>
> I didn't understand this error, what does it mean? It would be
> helpful to add a brief about what it means and why we are throwing it
> and/or rephrasing the error bit.
cbm_next_segment is supposed to be the lowest-numbered segment that
doesn't yet exist. Imagine that it's 4. But, suppose that the free
space map shows segment 4 as in use, even though the metapage's
cbm_next_segment value claims it's not allocated yet. Then maybe we
decide that the lowest-numbered free segment according to the
freespace map is 5, while meanwhile the metapage is pretty sure we've
never created 4. Then I think we'll end up here and trip over this
error check. To get more understanding of this, look at how
ConveyorBeltGetNewPage selects free_segno.
> Incorrect file name: s/cbmodify.c/cbxlog.c/
Right, thanks.
> + can_allocate_segment =
> + (free_segno_first_blkno < possibly_not_on_disk_blkno)
>
> The condition should be '<=' ?
It doesn't look that way to me. If they were equal, then that block
doesn't necessarily exist on disk ... in which case we should not
allocate. Am I missing something?
> + * ConveyorBeltPhysicalTruncate. For more aggressive cleanup options, see
> + * ConveyorBeltCompact or ConveyorBeltRewrite.
>
> Didn't find ConveyorBeltCompact or ConveyorBeltRewrite code, might yet
> to be implemented?
Right.
> + * the value computed here here if the entry at that offset is already
>
> "here" twice.
Oops.
> And few typos:
>
> othr
> semgents
> fucntion
> refrenced
> initialied
> remve
> extrordinarily
> implemenation
Wow, OK, that's a lot of typos.
Updated patch attached, also with a fix for the mistake in the readme
that Matthias found, and a few other bug fixes.
--
Robert Haas
EDB: http://www.enterprisedb.com
Attachment | Content-Type | Size |
---|---|---|
v2-0001-WIP-Conveyor-belt-storage.patch | application/octet-stream | 200.6 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2022-01-04 20:09:37 | Re: SKIP LOCKED assert triggered |
Previous Message | Stephen Frost | 2022-01-04 19:32:20 | Re: Add 64-bit XIDs into PostgreSQL 15 |