Re: pg15b2: large objects lost on upgrade
От | Jonathan S. Katz |
---|---|
Тема | Re: pg15b2: large objects lost on upgrade |
Дата | |
Msg-id | ddf43511-32fd-fc22-1b36-8e6c733a55b0@postgresql.org обсуждение исходный текст |
Ответ на | Re: pg15b2: large objects lost on upgrade (Peter Geoghegan <pg@bowt.ie>) |
Ответы |
Re: pg15b2: large objects lost on upgrade
|
Список | pgsql-hackers |
On 8/3/22 2:08 PM, Peter Geoghegan wrote: > On Wed, Aug 3, 2022 at 1:47 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Again, this seems to me to be breaking the test's real-world applicability >> for a (false?) sense of stability. > > I agree. > > A lot of the VACUUM test flappiness issues we've had to deal with in > the past now seem like problems with VACUUM itself, the test's design, > or both. For example, why should we get a totally different > pg_class.reltuples because we couldn't get a cleanup lock on some > page? Why not just make sure to give the same answer either way, > which happens to be the most useful behavior to the user? That way > the test isn't just targeting implementation details. After catching up (and reviewing approaches that could work while on poor wifi), it does make me wonder if we can have a useful test ready before beta 3. I did rule out wanting to do the "xid + $X" check after reviewing some of the output. I think that both $X could end up varying, and it really feels like a bandaid. Andres suggested upthread using "txid_current()" -- for the comparison, that's one thing I looked at. Would any of the XID info from "pg_control_checkpoint()" also serve for this test? If yes to the above, I should be able to modify this fairly quickly. Jonathan
В списке pgsql-hackers по дате отправления: