g.hintermayer@inode.at wrote:
> On Jun 18, 11:08 am, g.hinterma...@inode.at wrote:
> > On Jun 13, 2:35 pm, g.hinterma...@inode.at wrote:
> >
> > Can someone tell me if I should be concerned about this log entry ? My
> > database is quite large (~ 2G in PGDATA)
>
> BTW, I do not use autovacuum, and run vacuumdb on a weekly basis.
Ok, here is what I can tell you:
1. this message can only appear during checkpoint.
2. this message, by itself, is harmless. All it says is that it tried
to truncate (meaning, removing files previous to the segments in active
use) the multixact system (directory PGDATA/pg_multixact) and it
couldn't find an appropriate truncating point.
3. If it cannot find a truncating point, it logs this message and then
moves the "already truncated" point to the requested truncating point.
This means that some files might remain on disk. This is harmless
because they will be overwritten when the numbering mechanism wraps
around and creates the same files again.
Make sure we are actually talking about the same log message: it must
mention the directory "pg_multixact".
The only situation in which this could be an actual problem is when the
numbering is actually wrapping around very quickly, i.e. faster than
checkpoints. If you are using lots of multixacts then this may be
possible -- I am not sure. You use multixacts by creating shared tuple
locks, which in turn are created when foreign keys are checked by more
than one process at the same time.
Questions:
- what files are actually in PGDATA/pg_multixact/offsets and members?
- do the multixact counters increase quickly? You can check them with
pg_controldata
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
