| From: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | pgsql-hackers(at)postgresql(dot)org, Bruce Momjian <bruce(at)momjian(dot)us>, Shruthi Gowda <gowdashru(at)gmail(dot)com> |
| Subject: | Re: pg15b2: large objects lost on upgrade |
| Date: | 2022-07-02 15:49:17 |
| Message-ID: | 20220702154917.GM13040@telsasoft.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sat, Jul 02, 2022 at 08:34:04AM -0400, Robert Haas wrote:
> On Fri, Jul 1, 2022 at 7:14 PM Justin Pryzby <pryzby(at)telsasoft(dot)com> wrote:
> > I noticed this during beta1, but dismissed the issue when it wasn't easily
> > reproducible. Now, I saw the same problem while upgrading from beta1 to beta2,
> > so couldn't dismiss it. It turns out that LOs are lost if VACUUM FULL was run.
>
> Yikes. That's really bad, and I have no idea what might be causing it,
> either. I'll plan to investigate this on Tuesday unless someone gets
> to it before then.
I suppose it's like Bruce said, here.
https://www.postgresql.org/message-id/20210601140949.GC22012%40momjian.us
|One tricky case is pg_largeobject, which is copied from the old to new
|cluster since it has user data. To preserve that relfilenode, you would
|need to have pg_upgrade perform cluster surgery in each database to
|renumber its relfilenode to match since it is created by initdb. I
|can't think of a case where pg_upgrade already does something like that.
Rather than setting the filenode of the next object as for user tables,
pg-upgrade needs to UPDATE the relfilenode.
This patch "works for me" but feel free to improve on it.
| Attachment | Content-Type | Size |
|---|---|---|
| 0001-wip-preserve-relfilenode-of-pg_largeobject-and-its-i.patch | text/x-diff | 4.1 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Julien Rouhaud | 2022-07-02 15:52:08 | Re: pg15b2: large objects lost on upgrade |
| Previous Message | vignesh C | 2022-07-02 14:24:51 | Re: Support logical replication of DDLs |