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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Introduce wait_for_subscription_sync for TAP tests
Следующее
От: Robert Haas
Дата:
Сообщение: Re: pg15b2: large objects lost on upgrade