| From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Nitin Motiani <nitinmotiani(at)google(dot)com>, Hannu Krosing <hannuk(at)google(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: pg_upgrade: transfer pg_largeobject_metadata's files when possible |
| Date: | 2026-02-12 22:26:14 |
| Message-ID: | aY5ThhOKTKIe8S5t@nathan |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Feb 12, 2026 at 03:59:24PM -0600, Nathan Bossart wrote:
> On Thu, Feb 12, 2026 at 04:46:30PM -0500, Andres Freund wrote:
>> I guess you could instead generate a COPY using WITH OIDS. But it's probably
>> not worth having that path, given we already need to support COPY (SELECT ..).
>
> Ah, I forgot all about that COPY option...
>
>> as we'd just include the oid column without needing to somehow include it in
>> the attribute list.
>>
>> [...]
>>
>> I guess WITH OIDs also would avoid the need for this.
>
> Will give it a try.
So, in addition to hacking in the OIDS option to the COPY command executed
on the old server, we still need to hack the OID column into the column
list for the dumped COPY command (or omit the column list entirely for
pg_largeobject_metadata). That seems to result in roughly the same level
of hackery as before.
--
nathan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2026-02-12 22:29:02 | Re: AIX support |
| Previous Message | Tom Lane | 2026-02-12 22:22:03 | Re: AIX support |