Re: pg15b2: large objects lost on upgrade
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: "Jonathan S. Katz" <jkatz@postgresql.org>, Noah Misch <noah@leadboat.com>, Andrew Dunstan <andrew@dunslane.net>, Bruce Momjian <bruce@momjian.us>, Michael Paquier <michael@paquier.xyz>, Justin Pryzby <pryzby@telsasoft.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>,
Shruthi Gowda <gowdashru@gmail.com>
Date: 2022-08-02T19:23:26Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Revert recent changes to 002_pg_upgrade.pl.
- 6f7e7d0c482d 15.0 landed
- 87e22f675fd8 16.0 landed
-
Revise test case added in 43746996399541ecb5c7b188725a5f097c15ceae.
- d92f2bc0dae3 15.0 landed
- 212bdc0cbc32 16.0 landed
-
Use TRUNCATE to preserve relfilenode for pg_largeobject + index.
- bbe08b8869bd 16.0 landed
- 4ab5dae9472c 15.0 landed
-
Preserve relfilenode of pg_largeobject and its index across pg_upgrade.
- a2996478c32d 15.0 landed
- d498e052b4b8 16.0 landed
-
Have VACUUM warn on relfrozenxid "in the future".
- e83ebfe6d767 15.0 cited
-
Set relfrozenxid to oldest extant XID seen by VACUUM.
- 0b018fabaaba 15.0 cited
-
pg_upgrade: Preserve relfilenodes and tablespace OIDs.
- 9a974cbcba00 15.0 cited
-
Perform a lot more sanity checks when freezing tuples.
- 699bf7d05c68 11.0 cited
On Tue, Aug 2, 2022 at 1:12 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > Not sure what to make of this, except that maybe the test is telling > us about an actual bug of exactly the kind it's designed to expose. That could be, but what would the bug be exactly? It's hard to think of a more direct way of setting relminmxid and relfrozenxid than updating pg_class. It doesn't seem realistic to suppose that we have a bug where setting a column in a system table to an integer value sometimes sets it to a slightly larger integer instead. If the values on the new cluster seemed like they had never been set, or if it seemed like they had been set to completely random values, then I'd suspect a bug in the mechanism, but here it seems more believable to me to think that we're actually setting the correct values and then something - maybe autovacuum - bumps them again before we have a chance to look at them. I'm not quite sure how to rule that theory in or out, though. -- Robert Haas EDB: http://www.enterprisedb.com