On Tue, Jul 5, 2011 at 10:51 AM, Kevin Grittner
<Kevin.Grittner@wicourts.gov> wrote:
>> Is this still an open item?
>
> Yes, although I'm not clear on whether people feel it is one which
> needs to be fixed for 9.1 or left for 9.2.
>
> On a build with a BLCKSZ less than 8KB we would not get a warning
> before problems occurred, and we would have more serious problem
> involving potentially incorrect behavior. Tom questioned whether
> anyone actually builds with BLCKSZ less than 8KB, and I'm not
> altogether sure that SLRUs dealing with transaction IDs would behave
> correctly either.
>
> On block sizes larger than 8KB it will the warning if you burn
> through one billion transactions while holding one serializable read
> write transaction open, even though there won't be a problem. With
> the larger BLCKSZ values it may also generate log level messages
> about SLRU wraparound when that's not really a problem.
Well, as long as we can verify that OLDSERXID_MAX_PAGE has the same
value for BLCKSZ=8K before and after this patch, I don't see any real
downside to applying it. If, hypothetically, it's buggy, it's only
going to break things for non-default block sizes which are, by your
description, not correct right now anyway.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
