g.hintermayer@xxxxxxxx wrote: > On Jun 18, 11:08 am, g.hinterma...@xxxxxxxx wrote: > > On Jun 13, 2:35 pm, g.hinterma...@xxxxxxxx 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.
