On 08.06.2011 22:40, Kevin Grittner wrote:
> Heikki Linnakangas<heikki.linnakangas@enterprisedb.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.
I've committed your patch for now. It does in fact bring back the
original problem the clever but broken code was trying to address: if a
pg_serial is not needed for a very long time, the last segment that we
leave behind will eventually appear to be new again, and won't be
cleaned up until a lot more XIDs pass.
> 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....
Yeah, as far as I can see it's harmless except for the small waste of
disk space. We probably want to revisit this later, maybe still for 9.1
or maybe not, but for now I just put in a comment about it.
I also fixed the broken warning logic. Please double-check that too when
you get a chance.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
