Re: Potential stack overflow in incremental base backup

On Wed, Mar 6, 2024 at 6:29 AM Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote:
> On 2024-Mar-06, Thomas Munro wrote:
> > Even on the heap, 16GB is too much to assume we can allocate during a
> > base backup. I don't claim that's a real-world problem for
> > incremental backup right now in master, because I don't have any
> > evidence that anyone ever really uses --with-segsize (do they?), but
> > if we make it an initdb option it will be more popular and this will
> > become a problem. Hmm.
>
> Would it work to use a radix tree from the patchset at
> https://postgr.es/m/CANWCAZb43ZNRK03bzftnVRAfHzNGzH26sjc0Ep-sj8+w20VzSg@mail.gmail.com
> ?

Probably not that much, because we actually send the array to the
client very soon after we construct it:

push_to_sink(sink, &checksum_ctx, &header_bytes_done,
incremental_blocks,
sizeof(BlockNumber) * num_incremental_blocks);

This is hard to do without materializing the array somewhere, so I
don't think an alternate representation is the way to go in this
instance.

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