Re: pg15b2: large objects lost on upgrade
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
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-03T14:13:51Z
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
Robert Haas <robertmhaas@gmail.com> writes: > On Tue, Aug 2, 2022 at 3:51 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: >> I also think that ">=" is a sufficient requirement. > I don't really like this approach. Imagine that the code got broken in > such a way that relfrozenxid and relminmxid were set to a value chosen > at random - say, the contents of 4 bytes of unallocated memory that > contained random garbage. Well, right now, the chances that this would > cause a test failure are nearly 100%. With this change, they'd be > nearly 0%. If you have a different solution that you can implement by, say, tomorrow, then go for it. But I want to see some fix in there within about 24 hours, because 15beta3 wraps on Monday and we will need at least a few days to see if the buildfarm is actually stable with whatever solution is applied. A possible compromise is to allow new values that are between old value and old-value-plus-a-few-dozen. regards, tom lane