Re: pg_dump: Remove "blob" terminology - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pg_dump: Remove "blob" terminology
Date
Msg-id 1926086.1669990737@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_dump: Remove "blob" terminology  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Responses Re: pg_dump: Remove "blob" terminology  (Daniel Gustafsson <daniel@yesql.se>)
Re: pg_dump: Remove "blob" terminology  (Andrew Dunstan <andrew@dunslane.net>)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: Error-safe user functions
Next
From: Richard Guo
Date:
Subject: Is this an oversight in reparameterizing Memoize path?