On Mon, Dec 5, 2022 at 10:56 AM Tom Lane wrote:
> Interesting idea. We'd have to either read the TOC multiple times,
> or shove the LOB TOC entries into a temporary file, either of which
> has downsides.
I wonder if we'd need to read the TOC entries repeatedly, or just incrementally.
I haven't
Robert Haas writes:
> I wonder if we can't find a better solution than bunching TOC entries
> together. Perhaps we don't need every TOC entry in memory
> simultaneously, for instance, especially things like LOBs that don't
> have dependencies.
Interesting idea. We'd have to either read the TOC m
On Sat, Dec 3, 2022 at 11:07 AM Andrew Dunstan wrote:
> > Well, what this would lose is the ability to selectively restore
> > individual large objects using "pg_restore -L". I'm not sure who
> > out there might be depending on that, but if we assume that's the
> > empty set I fear we'll find out
On 02.12.22 09:34, Daniel Gustafsson wrote:
On 2 Dec 2022, at 08:09, Peter Eisentraut
wrote:
fixed
+1 on this version of the patch, LGTM.
committed
I also put back the old long options forms in the documentation and help but
marked them deprecated.
+ --blobs (deprecated)
While
On 2022-12-02 Fr 12:40, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 2022-12-02 Fr 09:18, Tom Lane wrote:
>>> 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
Andrew Dunstan writes:
> On 2022-12-02 Fr 09:18, Tom Lane wrote:
>> 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 pra
On 2022-12-02 Fr 09:18, Tom Lane wrote:
> 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
> On 2 Dec 2022, at 15:18, Tom Lane wrote:
> 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.
I have that on my TODO as well since
7da8823d83a2b66bdd917aa6cb2c5c2619d86011.ca...@credativ.de,
and having read this
Peter Eisentraut 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
> On 2 Dec 2022, at 08:09, Peter Eisentraut
> wrote:
> fixed
+1 on this version of the patch, LGTM.
> I also put back the old long options forms in the documentation and help but
> marked them deprecated.
+ --blobs (deprecated)
While not in scope for this patch, I wonder if we should ad
etc).
fixed
I also put back the old long options forms in the documentation and help
but marked them deprecated.
From e32d43952a4f2a054f25883c1136177cd1ad1fc3 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
Date: Fri, 2 Dec 2022 07:55:52 +0100
Subject: [PATCH v2] pg_dump: Remove "blob&q
> On 30 Nov 2022, at 08:04, Peter Eisentraut
> wrote:
>
> For historical reasons, pg_dump refers to large objects as "BLOBs". This term
> is not used anywhere else in PostgreSQL, and it also means something
> different in the SQL standard and other SQL systems.
>
> This patch renames internal
298 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
Date: Wed, 30 Nov 2022 07:52:19 +0100
Subject: [PATCH] pg_dump: Remove "blob" terminology
For historical reasons, pg_dump refers to large objects as "BLOBs".
This term is not used anywhere else in PostgreSQL, and it also means
s
13 matches
Mail list logo
