Re: SLRU limits

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>
Subject: Re: SLRU limits
Date: 2011-06-09 12:50:33
Message-ID: BANLkTimhxFEGKr3yyJqrErLAEbN2NCRjQw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jun 9, 2011 at 7:46 AM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)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

In response to

  • SLRU limits at 2011-06-09 11:46:39 from Heikki Linnakangas

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2011-06-09 13:13:16 Re: reducing the overhead of frequent table locks - now, with WIP patch
Previous Message Kevin Grittner 2011-06-09 12:14:25 Re: could not truncate directory "pg_serial": apparent wraparound