Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> On 08.06.2011 03:28, Kevin Grittner wrote:
>> We had a report of the subject message during testing a while
>> back and attempted to address the issue. It can result in a LOG
>< level message and the accumulation of files in the pg_serial SLRU
>> subdirectory. We haven't seen a recurrence, until I hit it
>> during testing of the just-posted patch for SSI DDL. I re-read
>> the code and believe that the attached is the correct fix.
>
> Doesn't this patch bring back the issue mentioned in the comment:
> the slru page might not get used again until we wrap-around?
In the previous attempt I thought it was looking at the allocated
files to assess that it was approaching wraparound. In looking at
the SLRU code last night, it seemed that it was really using the
"last zeroed" page as the comparison point, and wanted the
truncation point to precede that. Given that last night didn't seem
to be my sharpest hour, it would be wise to confirm this. This code
is pretty hard to test, since it only comes into play on overflow of
the predicate locking shared memory structures, so desk-checking is
important.
So, to directly address your question, if we don't overflow again
and go to the SLRU summary data, one file could sit in the pg_serial
directory indefinitely; but we should avoid the LOG message and the
accumulation of large numbers of such files -- if I'm reading the
SLRU code correctly....
-Kevin