Re: pg_upgrade failing for 200+ million Large Objects
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: "Kumar, Sachin" <ssetiya@amazon.com>, Jan Wieck <jan@wi3ck.info>,
Bruce Momjian <bruce@momjian.us>, Zhihong Yu <zyu@yugabyte.com>,
Andrew Dunstan <andrew@dunslane.net>,
Magnus Hagander <magnus@hagander.net>,
Robins Tharakan <tharakan@gmail.com>,
Peter Eisentraut <peter.eisentraut@enterprisedb.com>,
"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2024-01-12T22:57:24Z
Lists: pgsql-hackers
Nathan Bossart <nathandbossart@gmail.com> writes:
> On Wed, Dec 20, 2023 at 06:47:44PM -0500, Tom Lane wrote:
>> + char *cmdEnd = psprintf(" OWNER TO %s", fmtId(te->owner));
>> +
>> + IssueCommandPerBlob(AH, te, "ALTER LARGE OBJECT ", cmdEnd);
> This is just a nitpick, but is there any reason not to have
> IssueCommandPerBlob() accept a format string and the corresponding
> arguments?
The problem is how to combine the individual per-blob OID with the
command string given by the caller. If we want the caller to also be
able to inject data values, I don't really see how to combine the OID
with the va_args list from the caller. If we stick with the design
that the caller provides separate "front" and "back" strings, but ask
to be able to inject data values into those, then we need two va_args
lists which C doesn't support, or else an arbitrary decision about
which one gets the va_args. (Admittedly, with only one caller that
needs a non-constant string, we could make such a decision; but by the
same token we'd gain little.)
It'd be notationally simpler if we could have the caller supply one
string that includes %u where the OID is supposed to go; but then
we have problems if an owner name includes %. So on the whole I'm
not seeing anything much better than what I did. Maybe I missed
an idea though.
> Another nitpick: it might be worth moving these hard-wired constants to
> macros. Without a control switch, that'd at least make it easy for anyone
> determined to change the value for their installation.
OK.
regards, tom lane
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Count individual SQL commands in pg_restore's --transaction-size mode.
- 81db073a2878 17.0 landed
- 0f1290521504 18.0 landed
-
Reduce number of commands dumpTableSchema emits for binary upgrade.
- b3f0e0503f33 18.0 landed
- 2fa989e6a340 17.0 landed
-
Invent --transaction-size option for pg_restore.
- 959b38d770ba 17.0 landed
-
Rearrange pg_dump's handling of large objects for better efficiency.
- a45c78e3284b 17.0 landed
-
Add temporal PRIMARY KEY and UNIQUE constraints
- 46a0cd4cefb4 17.0 cited
-
Fix typo and case in messages
- 7d7ef075d2b3 17.0 cited