Re: pg_upgrade failing for 200+ million Large Objects

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Nathan Bossart <nathandbossart(at)gmail(dot)com>
Cc: "Kumar, Sachin" <ssetiya(at)amazon(dot)com>, Jan Wieck <jan(at)wi3ck(dot)info>, Bruce Momjian <bruce(at)momjian(dot)us>, Zhihong Yu <zyu(at)yugabyte(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Magnus Hagander <magnus(at)hagander(dot)net>, Robins Tharakan <tharakan(at)gmail(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_upgrade failing for 200+ million Large Objects
Date: 2024-01-12 22:57:24
Message-ID: 822538.1705100244@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Nathan Bossart <nathandbossart(at)gmail(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Davis 2024-01-12 23:06:26 Fix minor memory leak in connection string validation
Previous Message Nathan Bossart 2024-01-12 22:56:35 Re: pg_upgrade failing for 200+ million Large Objects