Re: SLRU limits

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: SLRU limits
Дата
Msg-id 9551.1307636693@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: SLRU limits  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Ответы Re: SLRU limits  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Re: SLRU limits  (Bruce Momjian <bruce@momjian.us>)
Список pgsql-hackers
Heikki Linnakangas <heikki.linnakangas@enterprisedb.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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Magnus Hagander
Дата:
Сообщение: Re: .gitignore for some of cygwin files
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: tuning autovacuum