On 08.06.2011 22:40, Kevin Grittner wrote:
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.
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
