Re: Trying out read streams in pgvector (an extension) - Mailing list pgsql-hackers

From Melanie Plageman
Subject Re: Trying out read streams in pgvector (an extension)
Date
Msg-id CAAKRu_Zwj83zCJhahhMO578-+JdfTbqMV_ktxr-XjiE8BHLo9g@mail.gmail.com
Whole thread Raw
In response to Re: Trying out read streams in pgvector (an extension)  (Nazir Bilal Yavuz <byavuz81@gmail.com>)
List pgsql-hackers
On Wed, Nov 19, 2025 at 2:28 AM Nazir Bilal Yavuz <byavuz81@gmail.com> wrote:
>
> > To make sure 1) distance isn't reset to a resume_distance from
> > read_stream_begin_relation() and 2) unexpected buffers aren't returned
> > from the read stream, we could error out in read_stream_resume() if
> > pinned_buffers > 0. And in read_stream_reset(), we would save distance
> > in resume_distance before clearing distance. That would allow calling
> > read_stream_resume() either if you called read_stream_reset() or if
> > you exhausted the stream yourself. See rough attached patch for a
> > sketch of this.
>
> This looks correct to me. What do you think about using an assert
> instead of erroring out?

I'm not totally opposed to this. My rationale for making it an error
is that the developer could have test cases where all the buffers are
consumed but the code is written such that that won't always happen.
Then if a real production query doesn't consume all the buffers, it
could return wrong results (I think). That will mean the user can't
complete their query until the extension author releases a new version
of their code. But I'm not sure what the right answer is here.

- Melanie



pgsql-hackers by date:

Previous
From: jian he
Date:
Subject: Re: ON CONFLICT DO SELECT (take 3)
Next
From: Álvaro Herrera
Date:
Subject: Re: Remove useless casts to (void *)