Re: pg_dump: largeobject behavior issues (possible bug)

Поиск
Список
Период
Сортировка
От Andrew Dunstan
Тема Re: pg_dump: largeobject behavior issues (possible bug)
Дата
Msg-id 55395F4F.3090101@dunslane.net
обсуждение исходный текст
Ответ на Re: pg_dump: largeobject behavior issues (possible bug)  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
Ответы Re: pg_dump: largeobject behavior issues (possible bug)  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On 04/23/2015 04:04 PM, Andrew Gierth wrote:
>>>>>> "Joshua" == Joshua D Drake <jd@commandprompt.com> writes:
>   Joshua> The database dumps fine as long as we don't dump large
>   Joshua> objects. However, if we try to dump the large objects, FreeBSD
>   Joshua> will kill pg_dump as it will consume all free memory and
>   Joshua> swap. With Andrew's help we were able to determine the
>   Joshua> following:
>
>   Joshua> There is a memory cost of about 160 bytes per largeobject.
>
> I may have the exact number here wrong, it was just a quick eyeball of
> the data structures (and depends on malloc overheads anyway).
>
> The relevant code is getBlobs in pg_dump.c, which queries the whole of
> pg_largeobject_metadata without using a cursor (so the PGresult is
> already huge thanks to having >100 million rows), and then mallocs a
> BlobInfo array and populates it from the PGresult, also using pg_strdup
> for the oid string, owner name, and ACL if any.
>


I'm surprised this hasn't come up before. I have a client that I 
persuaded to convert all their LOs to bytea fields because of problems 
with pg_dump handling millions of LOs, and kept them on an older 
postgres version until they made that change.

cheers

andrew






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

Предыдущее
От: David Steele
Дата:
Сообщение: Re: tablespaces inside $PGDATA considered harmful
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: INSERT ... ON CONFLICT IGNORE (and UPDATE) 3.0