Tom Lane wrote:
> You haven't really thought this through: what would happen after the
> file filled up? If Postgres truncates it then you'd instantly lose
> all log entries before that time, which is surely not what you want.
>
Unfortunately the drive the database are on have very limited drive
space and with my recent problem with table oid's they grow much quicker
then I'd like. Having the drives fill up would be bad. The database
itself is one of many, so if a db goes down apps will just switch to one
of the other db's. The logs would normal have room to grow for days,
but if they suddenly start spewing errors, i'd still be able to sleep at
night. It's really just a temp work around until I resolve the oid
issues.
btw, it's not the typical use of a database. The databases are built
from source data files and can be rebuilt easily without any data loss.
It's probably part of the problem that I'm having with oid's, tables are
regularly dropped and recreated. So far the evidence seems to point to
these table recreations and prepared statements, i'm trying to work on a
test case this weekend to prove/disprove my theory.
> The usual arrangement is to set up a rotating cycle of log file names,
> such as one for each day of the week if you want a week's worth of log
> history, or one for each hour of the day if you want a day's worth,
> etc. Then the oldest file gets truncated and rewritten each time the
> logger shifts to a new file name.
Agreed!
> To do this, you change log_filename
> to use a suitable %-item in the file name. See the examples in the manual.
>
Sorry, I should know better.. I'll re-read the docs on this. I should
have before my post.. :( :(
> regards, tom lane
>
