Re: Potential stack overflow in incremental base backup

Поиск
Список
Период
Сортировка
Искать
От
Robert Haas
Тема
Re: Potential stack overflow in incremental base backup
Дата
Msg-id
CA+TgmoZoHXOCWBUJuPP2g7U2_xSjRJAwum8kSRCRUTMesVfgoA@mail.gmail.com
Ответ на
Список
Дерево обсуждения
Potential stack overflow in incremental base backup Thomas Munro <thomas.munro@gmail.com>
Re: Potential stack overflow in incremental base backup Alvaro Herrera <alvherre@alvh.no-ip.org>
Re: Potential stack overflow in incremental base backup Robert Haas <robertmhaas@gmail.com>
Re: Potential stack overflow in incremental base backup Robert Haas <robertmhaas@gmail.com>
Re: Potential stack overflow in incremental base backup Thomas Munro <thomas.munro@gmail.com>
Re: Potential stack overflow in incremental base backup Thomas Munro <thomas.munro@gmail.com>
Re: Potential stack overflow in incremental base backup Robert Haas <robertmhaas@gmail.com>
Re: Potential stack overflow in incremental base backup Thomas Munro <thomas.munro@gmail.com>
Re: Potential stack overflow in incremental base backup Robert Haas <robertmhaas@gmail.com>
Re: Potential stack overflow in incremental base backup Thomas Munro <thomas.munro@gmail.com>
On Wed, Mar 6, 2024 at 6:29 AM Alvaro Herrera  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


В списке pgsql-hackers по дате отправления
От: Alvaro Herrera
Дата:
От: Alvaro Herrera
Дата:
FAQ