Heikki Linnakangas wrote: > * The oldserxid code is broken for non-default BLCKSZ. > o The warning will come either too early or too late > o There is no safeguard against actually wrapping around the > SLRU, just the warning > o I'm suspicious of the OldSerXidPagePrecedesLogically() logic > with 32k BLCKSZ. In that case, OLDSERXID_MAX_PAGE is a larger > than necessary to cover the whole range of 2^32 transactions, > so at high XIDs, say 2^32-1, doesn't it incorrectly think that > low XIDs, say 10, are in the past, not the future?
It took me a while to see these problems because somehow I had forgotten that SLRU_PAGES_PER_SEGMENT was a literal of 32 rather than being based on BLCKSZ. After I rediscovered that, your concern was clear enough. I think the attached patch addresses the problem with the OldSerXidPagePrecedesLogically() function, which strikes me as the most serious issue. Based on the calculation from the attached patch, it would be easy to adjust the warning threshold, but I'm wondering if we should just rip it out instead. As I mentioned in a recent post based on reviewing your concerns, with an 8KB BLCKSZ the SLRU system will start thinking we're into wraparound at one billion transactions, and refuse to truncate segment files until we get down to less than that, but we won't actually overwrite anything and cause SSI misbehaviors until we eat through two billion (2^31 really) transactions while holding open a single read-write transaction. At that point I think PostgreSQL has other defenses which come into play. With the attached patch I don't think we can have any such problems with a *larger* BLCKSZ, so the only point of the warning would be for a BLCKSZ of 4KB or less. Is it worth carrying the warning code (with an appropriate adjustment to the thresholds) or should we drop it? -Kevin
ssi-slru-maxpage.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers