Re: pg15b2: large objects lost on upgrade
От | Jonathan S. Katz |
---|---|
Тема | Re: pg15b2: large objects lost on upgrade |
Дата | |
Msg-id | 98286e9b-8fe6-554e-c23f-d67a3df2c30d@postgresql.org обсуждение исходный текст |
Ответ на | Re: pg15b2: large objects lost on upgrade (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: pg15b2: large objects lost on upgrade
|
Список | pgsql-hackers |
On 8/2/22 3:39 PM, Tom Lane wrote: > "Jonathan S. Katz" <jkatz@postgresql.org> writes: >> On 8/2/22 3:23 PM, Robert Haas wrote: >>> I'm not quite sure how to rule that theory in or out, though. > >> Without overcomplicating this, are we able to check to see if autovacuum >> ran during the course of the test? > > Looks like we're all thinking along the same lines. > > While not smoking guns, these definitely prove that autovac was active. > If that is the explanation, then it leaves us with few good options. > I am not in favor of disabling autovacuum in the test: ordinary > users are not going to do that while pg_upgrade'ing, so it'd make > the test less representative of real-world usage, which seems like > a bad idea. We could either drop this particular check again, or > weaken it to allow new relfrozenxid >= old relfrozenxid, likewise > relminxid. The test does look helpful and it would catch regressions. Loosely quoting Robert on a different point upthread, we don't want to turn off the alarm just because it's spuriously going off. I think the weakened check is OK (and possibly mimics the real-world where autovacuum runs), unless you see a major drawback to it? Jonathan
Вложения
В списке pgsql-hackers по дате отправления: