>>> Aidan Van Dyk <ai...@highrise.ca> 01/09/09 10:22 AM >>> > The reason *I* shy way from pg_lesslog and pg_clearxlogtail, is that > they seem to possibly be frail... I'm just scared of somethign > changing in PG some time, and my pg_clearxlogtail not nowing, me > forgetting to upgrade, and me not doing enough test of my actually > restoring backups... A fair concern. I can't speak about pglesslog, but pg_clearxlogtail goes out of its way to minimize this risk. Changes to log records themselves can't break it; it is only dependent on the partitioning. It bails with a message to stderr and a non-zero return code if it finds anything obviously wrong. It also checks the WAL format for which it was compiled against the WAL format on which it was invoked, and issues a warning if they don't match. We ran into this once on a machine running multiple releases of PostgreSQL where the archive script invoked the wrong executable. It worked correctly in spite of the warning, but the warning was enough to alert us to the mismatch and change the path in the archive script. -Kevin
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
