On Mon, 2005-01-24 at 18:43 -0500, Tom Lane wrote:
> Well, the thing that's bothering me is that you are undoing a number of
> changes that we'll probably just have to redo later; with consequently
> *two* chances to introduce bugs.
I'm not sure if we should apply this patch to both HEAD and
REL8_0_STABLE, or just the latter. I would guess there is no IP reason
to remove ARC from HEAD as well; while it might introduce complications
in backporting changes from HEAD, those same complications were present
through most of the 8.0 cycle (i.e. HEAD used a different replacement
policy than REL7_4_STABLE did).
> If the problem is that the current freelist.c API exposes too much about
> the ARC implementation, the answer to that is not to go back to exposing
> the LRU-list implementation; it's to generalize the API.
That would be one approach, yeah. My goal was to keep the code simple
and reasonably similar to the 7.4 codebase (which has gotten a lot more
testing than the ARC code, in addition to the fact that the ARC APIs
aren't really appropriate for an LRU implementation). Worrying about the
right freelist.c APIs seemed a little beside the point -- I didn't want
to make _any_ assumptions about how the code is going to look in 8.1, as
it may be fundamentally different.
-Neil
