On Thu, Jun 9, 2011 at 7:46 AM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:
> While reviewing the SLRU code in predicate.c again, I remembered this old
> thread:
>
> http://archives.postgresql.org/pgsql-hackers/2010-12/msg02374.php
>
> SLRU has a limit of 64k segment files, because the files are named using
> four hex digits like "00CE". Kevin's math shows that that's just enough to
> store 2^32 four-byte integers, which wasn't enough for predicate.c, which
> needs to store uint64s. Kevin worked around that by simply limiting the max
> range of open xids to fit the SLRU limit, ie. 2^31. However, that math was
> based on 8k block size, and the situation is worse for smaller block sizes.
> If you set BLCKSZ to 2048 or less, pg_subtrans can only hold 1 billion
> transactions. With 1024 block size, only half a billion.
I'm pretty unexcited about this. It's not terribly sane to keep a
transaction open for half a billion XIDs anyway, because of VACUUM.
And I would guess that there's a lot more interest in raising BLCKSZ
than lowering it. It might not be a bad idea to adopt the fix you
propose anyway, but it doesn't seem urgent.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
