Alvaro Herrera wrote:
> I think the query above is correct. One possible quibble is a FFFF
> segment that isn't allocated in full. I don't think this is a problem,
> because although the 0000 file would survive deletion, it would be
> overwritten with zeroes as soon as the counter wraps around. Since 0000
> is seen as "in the future" as soon as file 8000 starts being used, it
> shouldn't be a problem there.
... that said, there is a wraparound check in SimpleLruTruncate: if you
are using file 8000 and above, slru.c refuses to remove the old files
because it believes you may have already suffered wraparound, and you
would get a WARNING message every time the truncation was attempted.
The warnings would probably be pretty much invisible because of their
low frequency. This might be improved by my commit this afternoon,
which should cause multixact truncations to be attempted much more
often. In any case, just removing the offending offsets/0000 file
should clear it up.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services