Re: SLRU limits

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, 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 16:24:53
Message-ID: 9551.1307636693@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
> On 09.06.2011 15:50, Robert Haas wrote:
>> 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.

> I guess we could fix pg_subtrans by not allowing BLCKSZ < 8k. That
> leaves the problem with pg_serial. Kevin has already worked around, but
> I'm not very happy with that workaround.

> If we don't want to change it wholesale, one option would be to support
> different lengths of filenames in slru.c for different slrus. At a quick
> glance, it seems pretty easy. That would allow keeping clog unchanged -
> that's the one that's most likely to have unforeseen consequences if
> changed. pg_subtrans and pg_serial are more ephemeral, they don't need
> to be retained over shutdown, so they seem less likely to cause trouble.
> That seems like the best option to me.

I agree with Robert that this is completely not urgent. If you want to
fool with it for 9.2, fine, but let's not destabilize 9.1 for it.

(BTW, while I've not looked at the SLRU code in several years, I'm quite
unconvinced that this is only a matter of filename lengths.)

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2011-06-09 16:25:00 Re: tuning autovacuum
Previous Message Magnus Hagander 2011-06-09 16:13:04 Re: .gitignore for some of cygwin files