On Sun, Jun 19, 2011 at 7:17 PM, Kevin Grittner
<Kevin.Grittner@wicourts.gov> wrote:
> 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?
Is this still an open item?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company