Re: have SLRU truncation use callbacks

Hi,

Currently, the mechanism that SLRU uses to truncate directory entries is
hardcoded in SlruScanDirectory. It receives a cutoff page number and a
boolean flag; segments found in the SLRU directory that are below the
cutoff are deleted -- iff the flag is true.

This is fine for most current uses, with one exception, but it is a bit
too ad-hoc. The exception is the new NOTIFY code (async.c); on
postmaster (re)start, that module wants to simply zap all files found in
the directory. So it forcibly sets a different "pagePrecedes" routine,
then calls the truncation procedure with a made-up cutoff page.

Also, clog.c has a check that it scans the directory to figure out if
any segments would be removed, were we to do the thing for real. (This
is so that it can skip WAL flush in case none would).

(Now, this code is also getting in the way of some changes I want to do
on multixact truncation for the keylocks patch; hence the motivation.
But I think these changes stand on their own, merely on code clarity
grounds).

So what I propose is that we turn SlruScanDirectory into a mere
directory walker, and it invokes a callback on each file. We provide
three callbacks: one that simply removes everything (for NOTIFY); one
that removes everything before a given cutoff page; and a simple one
that reports "is there any removable file given this cutoff", for clog.c
uses.

Patch is attached.

Opinions?

--
Álvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>

Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote:

> But I think these changes stand on their own, merely on code
> clarity grounds).

After a quick scan, I think it helps with that. This was a messy
area to deal with in SSI given the old API; with this change I think
we could make that part of the SSI code clearer and maybe clean up
unneeded files in a couple places where cleanup under the old API
was judged not to be worth the code complexity needed to make it
happen.

-Kevin

Excerpts from Kevin Grittner's message of jue sep 29 14:51:38 -0300 2011:
> Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote:
>
> > But I think these changes stand on their own, merely on code
> > clarity grounds).
>
> After a quick scan, I think it helps with that. This was a messy
> area to deal with in SSI given the old API; with this change I think
> we could make that part of the SSI code clearer and maybe clean up
> unneeded files in a couple places where cleanup under the old API
> was judged not to be worth the code complexity needed to make it
> happen.

Thanks for the review. I just pushed this. Note I didn't touch the
predicate.c stuff at all -- I leave that to you, if you're so inclined :-)

--
Álvaro Herrera <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support