Re: Out of memory error handling in frontend code

Поиск
Список
Период
Сортировка
От Frédéric Yhuel
Тема Re: Out of memory error handling in frontend code
Дата
Msg-id 5a3058d1-1810-5a72-c50e-18df2de56fdf@dalibo.com
обсуждение исходный текст
Ответ на Re: Out of memory error handling in frontend code  (Daniel Gustafsson <daniel@yesql.se>)
Список pgsql-hackers
Hi Daniel,

Thank you for your answer.

On 9/28/23 14:02, Daniel Gustafsson wrote:
>> On 28 Sep 2023, at 10:14, Frédéric Yhuel <frederic.yhuel@dalibo.com> wrote:
> 
>> After some time, we understood that the 20 million of large objects were responsible for the huge memory usage (more
than10 GB) by pg_dump.
 
> 
> This sounds like a known issue [0] which has been reported several times, and
> one we should get around to fixing sometime.
>

Indeed, I saw some of these reports afterwards :)

>> I think a more useful error message would help for such cases.
> 
> Knowing that this is case that pops up, I agree that we could do better around
> the messaging here.
> 
>> I haven't try to get the patch ready for review, I know that the format of the messages isn't right, I'd like to
knowwhat do you think of the idea, first.
 
> 
> I don't think adding more details is a bad idea, but it shouldn't require any
> knowledge about internals so I think messages like the one below needs to be
> reworded to be more helpful.
> 
> +    if (loinfo == NULL)
> +    {
> +        pg_fatal("getLOs: out of memory");
> +    }
> 

OK, here is a second version of the patch.

I didn't try to fix the path getLOs -> AssignDumpId -> catalogid_insert 
-> [...] -> catalogid_allocate, but that's annoying because it amounts 
to 11% of the memory allocations from valgrind's output.

Best regards,
Frédéric
Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Shlok Kyal
Дата:
Сообщение: Re: pg_ctl start may return 0 even if the postmaster has been already started on Windows
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: How to update unicode mapping table?