Neil Conway <neilc@samurai.com> writes:
> Well, you've suggested that I should try and reduce the API churn caused
> by the patch. As I said on -patches, I don't really see this as an issue
> if we just apply the patch to REL8_0_STABLE.
If we do that then the patch will go out with essentially no testing
beyond your own; an idea that doesn't fill me with confidence.
> I think the biggest area of concern with the LRU patch is how it changes
> bgwriter behavior.
The easiest way to handle that is to keep storing a full list of all the
buffers in freelist.c, instead of reverting to the pre-8.0 data structure.
(Of course, if we decide we *want* to change the bgwriter behavior, it's
a different story.)
> I think it would be better to have a few weeks of beta prior to 8.0.2
> and resolve the problem here and now, rather than crippling the 8.1
> cycle (as the no-initdb policy would) or waiting for the problem to
> *really* become serious (as the "no action needed now" policy would).
I'm leaning in that direction too, but I think that the only way to get
any meaningful testing is to have the patch in HEAD as well as the back
branch. So I want something that doesn't undo more than the minimum
necessary to remove the ARC algorithm.
I don't have time to deal with this today or tomorrow, but once the
security releases are out, I will look at developing an LRU patch that
fits with my ideas about how to do it.
regards, tom lane