SLRU limits

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Cc: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>
Subject: SLRU limits
Date: 2011-06-09 11:46:39
Message-ID: 4DF0B29F.1080104@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2011-06-09 12:02:03 Re: Invalid byte sequence for encoding "UTF8", caused due to non wide-char-aware downcase_truncate_identifier() function on WINDOWS
Previous Message Kohei KaiGai 2011-06-09 10:17:07 [v9.2] sepgsql - userspace access vector cache (Re: [v9.1] sepgsql - userspace access vector cache)