Re: pg15b2: large objects lost on upgrade
От | Robert Haas |
---|---|
Тема | Re: pg15b2: large objects lost on upgrade |
Дата | |
Msg-id | CA+TgmoYqSrO-dSP6up31gv5F+1-zM-5exjKw2BU6w+FtzAzNhA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pg15b2: large objects lost on upgrade (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: pg15b2: large objects lost on upgrade
Re: pg15b2: large objects lost on upgrade Re: pg15b2: large objects lost on upgrade |
Список | pgsql-hackers |
On Tue, Aug 2, 2022 at 3:51 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > 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? > > I also think that ">=" is a sufficient requirement. It'd be a > bit painful to test if we had to cope with potential XID wraparound, > but we know that these installations haven't been around nearly > long enough for that, so a plain ">=" test ought to be good enough. > (Replacing the simple "eq" code with something that can handle that > doesn't look like much fun, though.) 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%. -- Robert Haas EDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: