Re: pg_upgrade failing for 200+ million Large Objects

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: pg_upgrade failing for 200+ million Large Objects
Дата
Msg-id 822538.1705100244@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: pg_upgrade failing for 200+ million Large Objects  (Nathan Bossart <nathandbossart@gmail.com>)
Список 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



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

Предыдущее
От: Nathan Bossart
Дата:
Сообщение: Re: pg_upgrade failing for 200+ million Large Objects
Следующее
От: Jeff Davis
Дата:
Сообщение: Fix minor memory leak in connection string validation