Re: SLRU limits - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: SLRU limits
Date
Msg-id 4E9829F60200002500041FC0@gw.wicourts.gov
Whole thread Raw
In response to Re: SLRU limits  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
Bruce Momjian <bruce@momjian.us> wrote:
> Is this a TODO?
> Tom Lane wrote:
>> Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
>>> 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.)
I think it should be.  I agree that the workaround is kinda ugly,
and this is really the only clean solution I see.  I don't think
it's so ugly that it takes precedence over trying to bring some of
Robert's LW locking improvements into the SSI area, so this one is
likely not to get into 9.2, in spite of appearing to be a smaller
change.  So a TODO entry seems like the right way to deal with it.
-Kevin


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Call stacks and RAISE INFO
Next
From: Josh Berkus
Date:
Subject: Re: Call stacks and RAISE INFO