Re: BUG #5915: OldSerXidAdd inflates pg_serial too much
От | Heikki Linnakangas |
---|---|
Тема | Re: BUG #5915: OldSerXidAdd inflates pg_serial too much |
Дата | |
Msg-id | 4D714A6B.3030506@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: BUG #5915: OldSerXidAdd inflates pg_serial too much ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>) |
Ответы |
Re: BUG #5915: OldSerXidAdd inflates pg_serial too much
Re: BUG #5915: OldSerXidAdd inflates pg_serial too much |
Список | pgsql-bugs |
On 04.03.2011 21:26, Kevin Grittner wrote: > "YAMAMOTO Takashi"<yamt@mwd.biglobe.ne.jp> wrote: > >> a seemingly wrong math in OldSerXidAdd makes it busy writing zeros >> to pg_serial. >> >> [patch] > > Your fix looks correct to me -- we want to get from a SLRU segment > number to the first page of that segment, so SLRU_PAGES_PER_SEGMENT > is the right multiplier. > > Thanks! > > While I was looking at it, I noticed some obsolete comment lines > which should be removed. Trivial patch attached. Hmm, if I'm reading that function correctly, it makes sure that when headPage < 0 (which implies that the SLRU has not been used since startup, right? ), it zeroes out the whole SLRU file, not only the currently active region. At least pg_subtrans doesn't seem to bother with that, StartupSubTrans only zeroes the active region. I wonder if we should move the responsibility of truncating the SLRU to checkpoint. At the moment, it's done in OldSerXidSetActiveSerXmin(), while the callers are holding SerializableXactHashLock in exclusive mode. While it'll probably go quickly in practice, it still seems like there's a risk of stalling all new transactions for a few seconds while that happens. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-bugs по дате отправления: