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.
It's awfully late in the release cycle, but how about we add another
digit to the filenames used by SLRU, to up the limit? At a quick glance,
I don't see any protection against wrapping around page numbers in
subtrans.c, so that ought to be fixed somehow. And it would make the
SLRU code in predicate.c simpler (I note that the warning logic at least
is wrong as it is - it doesn't take XID wrap-around into account).
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
