Le 7 juil. 09 à 21:12, Tom Lane a écrit :
Heikki Linnakangas <heikki.linnakan...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
