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
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 |