Le 7 juil. 09 à 21:12, Tom Lane a écrit :
> Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
>> And I'm sure people will want the option to retain WAL longer in the
>> master, to avoid an expensive resync if the slave falls behind. It
>> would
>> be simple to provide a GUC option for "always retain X GB of old
>> WAL in
>> pg_xlog".
>
> Right, we would want to provide some more configurability on the
> when-to-recycle-WAL decision than there is now. But the basic point
> is that I don't see the master pg_xlog as being a long-term archive.
> The amount of back WAL that you'd want to keep there is measured in
> minutes or hours, not weeks or months.
Could we add yet another postmaster specialized child to handle the
archive, which would be like a default archive_command implemented in
core. This separate process could then be responsible for feeding the
slave(s) with the WAL history for any LSN not available in pg_xlog
anymore.
The bonus would be to have a good reliable WAL archiving default setup
for simple PITR and simple replication setups. One of the reasons PITR
looks so difficult is that it involves reading a lot of documentation
then hand-writing scripts even in the simple default case.
> (If nothing else, there is no point in keeping so much WAL that
> catching
> up by scanning it would take longer than taking a fresh base backup.
> My impression from recent complaints about our WAL-reading speed is
> that
> that might be a pretty tight threshold ...)
Could the design above make it so that your later PITR backup is
always an option for setting up a WAL Shipping slave?
Regards,
--
dim