Re: Streamify more code paths

Hi,

On Mon, 3 Aug 2026 at 15:25, Mihail Nikalayeu <mihailnikalayeu(at)gmail(dot)com> wrote:
>
> While prototyping with a stress suite, I found memory corruption (and
> possibly data corruption) issues related to those changes.
>
> Issues is related to how the newer bfa3c4f106 affects the old 293e24e507.
>
> The 293e24e507 caches the metapage as a pointer, but
> read_stream_begin_relation may cause that pointer to become freed
> because of:
>
> hashbulkdelete() hash.c:543
> read_stream_begin_relation(READ_STREAM_MAINTENANCE, ...)
> read_stream_begin_impl() read_stream.c:806
> get_tablespace_maintenance_io_concurrency(tablespace_id)
> get_tablespace() spccache.c
> SearchSysCache1(TABLESPACEOID, ...) ← cold cache → catalog scan
> table_open(pg_tablespace)
> LockRelationOid(1213) lmgr.c:136
> AcceptInvalidationMessages() ← the flush point
>
> causing something like:
>
> ERROR: could not open file "base/5/16388.1" (target block 2139062145):
> previous segment is only 66 blocks
> CONTEXT: while scanning relation "public.t"

You are right, nice catch!

> The simplest fix is to reorder a few lines of code - attached (with a
> test generated by Claude based on my instructions).

I agree with you, fix LGTM.

> But probably we should think broader to avoid such issues in the future.

I am not sure how we can enforce this with a code check. Perhaps we
can add a comment to the read_stream code, but I am not sure how
effective that would be.

--
Regards,
Nazir Bilal Yavuz
Microsoft