Re: pg_dump: Remove "blob" terminology

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: pg_dump: Remove "blob" terminology
Дата
Msg-id 1926086.1669990737@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: pg_dump: Remove "blob" terminology  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Ответы Re: pg_dump: Remove "blob" terminology  (Daniel Gustafsson <daniel@yesql.se>)
Re: pg_dump: Remove "blob" terminology  (Andrew Dunstan <andrew@dunslane.net>)
Список pgsql-hackers
Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
> On 30.11.22 09:07, Daniel Gustafsson wrote:
>> Should BLOB be changed to BLOBS here (and in similar comments) to make it
>> clearer that it refers to the archive entry and the concept of a binary large
>> object in general?

> I changed this one and went through it again to tidy it up a bit more.
> (There are both "BLOB" and "BLOBS" archive entries, so both forms still
> exist in the code now.)

I've not read this patch and don't have time right this moment, but
I wanted to make a note about something to have in the back of your
head: we really need to do something about situations with $BIGNUM
large objects.  Currently those tend to run pg_dump or pg_restore
out of memory because of TOC bloat, and we've seen multiple field
reports of that actually happening.

The scheme I've vaguely thought about, but not got round to writing,
is to merge all blobs with the same owner and ACL into one TOC entry.
One would hope that would get it down to a reasonable number of
TOC entries in practical applications.  (Perhaps there'd need to be
a switch to make this optional.)

I'm not asking you to make that happen as part of this patch, but
please don't refactor things in a way that will make it harder.

            regards, tom lane



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Error-safe user functions
Следующее
От: Richard Guo
Дата:
Сообщение: Is this an oversight in reparameterizing Memoize path?