Re: pg15b2: large objects lost on upgrade
От | Jonathan S. Katz |
---|---|
Тема | Re: pg15b2: large objects lost on upgrade |
Дата | |
Msg-id | f0c60283-1c3d-0f0e-166a-b667c154fe0a@postgresql.org обсуждение исходный текст |
Ответ на | 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 |
Список | pgsql-hackers |
On 8/3/22 4:19 PM, Tom Lane wrote: > "Jonathan S. Katz" <jkatz@postgresql.org> writes: >> 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. > > It is that. I wouldn't feel comfortable with $X less than 100 or so, > which is probably sloppy enough to draw Robert's ire. Still, realizing > that what we want right now is a band-aid for 15beta3, I don't think > it's an unreasonable short-term option. Attached is the "band-aid / sloppy" version of the patch. Given from the test examples I kept seeing deltas over 100 for relfrozenxid, I chose 1000. The mxid delta was less, but I kept it at 1000 for consistency (and because I hope this test is short lived in this state), but can be talked into otherwise. >> 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? > > I like the idea of txid_current(), but we have no comparable > function for mxid do we? While you could get both numbers from > pg_control_checkpoint(), I doubt that's sufficiently up-to-date. ...unless we force a checkpoint in the test? Jonathan
Вложения
В списке pgsql-hackers по дате отправления: