>>> Aidan Van Dyk <aidan@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
