[resend, because of apparent failure to hit the list] Bruce Momjian wrote: > I am dismayed that we are using a 16MB file for monitoring archive > activity. Can't you use pg_current_xlog_location() and only check > for an archive file when that location changes? Hmmm.... Let me think about that. The intent was to check the end-to-end health of the PITR backups. The current process ensures that the archive command is working, the crontab scripts to copy the files are working (they get copied from the database server to multiple locations), and that the one copied to our central location applies cleanly to a warm standby (thereby providing confirmation of the health of that process). I'd have to think about how much we would lose with the change you suggest, and how much we'd care about that. I guess in a pinch we could always use a crontab job to force something to the WAL files periodically, but now that the system is proven and "settled in", perhaps constant validation of some of those points is overkill. By the way a near-empty WAL file is only 16KB by the time pg_clearxlogtail and gzip get done chewing on it, and we have a parallel stream of data from our application which allows us to keep the archive frequency to once per hour. Not everyone is going to be in this position, though, so I can understand the motivation to change it. > Is there a TODO here? Well, if I'm the only one who likes the status quo, I'm not sure that should preclude a change that would benefit others. I'm sure we can code around it one way or another. Perhaps some of the new monitoring functions in 9.0 will help. I'll have to take a look. Seriously, if there would be significant benefit to others, don't let me be the spoiler here; we'll sort it out. -Kevin
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
