Heikki Linnakangas <heikki.linnakan...@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. 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
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers