Re: testing HS/SR - 1 vs 2 performance
От | Florian Pflug |
---|---|
Тема | Re: testing HS/SR - 1 vs 2 performance |
Дата | |
Msg-id | A19FEFA9-6AE5-429C-A177-1BE5928C1914@phlo.org обсуждение исходный текст |
Ответ на | Re: testing HS/SR - 1 vs 2 performance (Simon Riggs <simon@2ndQuadrant.com>) |
Список | pgsql-hackers |
On Apr 21, 2010, at 16:49 , Simon Riggs wrote: > On Wed, 2010-04-21 at 16:22 +0200, marcin mank wrote: > >> Is that not a good idea that (at least for dev-builds, like with >> enable-cassert) the xid counter start at like 2^31 - 1000 ? It could >> help catch some bugs. > > It is a good idea, I'm sure that would help catch bugs. > > It wouldn't help here because the case in doubt is whether it's possible > to have an xid still showing in memory arrays from the last time the > cycle wrapped. It isn't. These things aren't random. These numbers are > extracted directly from activity that was occurring on the primary and > regularly checked and cleaned as the standby runs. > > So you'll need to do 2^31 transactions to prove this isn't true, which > isn't ever going to happen in testing with an assert build and nobody > with that many transactions would run an assert build anyway. ISTM that there's no need to actually execute 2^31 transactions to trigger this bug (if it actually exists), it'd be sufficientto increment the xid counter by more than one each time a xid is assigned, no? Or would that trip snapshot creation on the standby? best regards, Florian Pflug
В списке pgsql-hackers по дате отправления: