On Thu, Jun 9, 2011 at 7:46 AM, Heikki Linnakangas <heikki.linnakan...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
