On Tue, Jul 5, 2011 at 10:51 AM, Kevin Grittner <kevin.gritt...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers