Re: pg15b2: large objects lost on upgrade
От | Peter Geoghegan |
---|---|
Тема | Re: pg15b2: large objects lost on upgrade |
Дата | |
Msg-id | CAH2-Wz=a7Mw4oKOXATfsK4UQ20H96QxULo0QRRCy0AVWodVYKQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pg15b2: large objects lost on upgrade (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Tue, Aug 2, 2022 at 12:32 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > Hmmm ... now that you mention it, I see nothing in 002_pg_upgrade.pl > that attempts to turn off autovacuum on either the source server or > the destination. So one plausible theory is that autovac moved the > numbers since we checked. It's very easy to believe that my work in commit 0b018fab could make that happen, which is only a few months old. It's now completely routine for non-aggressive autovacuums to advance relfrozenxid by at least a small amount. For example, when autovacuum runs against either the tellers table or the branches table during a pgbench run, it will now advance relfrozenxid, every single time. And to a very recent value. This will happen in spite of the fact that no freezing ever takes place -- it's just a consequence of the oldest extant XID consistently being quite young each time, due to workload characteristics. -- Peter Geoghegan
В списке pgsql-hackers по дате отправления: