On Sat, Dec 19, 2009 at 1:03 AM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:
> I don't think it's worthwhile to modify pg_stop_backup() like that. We
> should address the general problem. At the moment, you're fine if you
> also configure WAL archiving and log file shipping, but it would be nice
> to have some simpler mechanism to avoid the problem. For example, a GUC
> in master to retain all log files (including backup history files) for X
> days. Or some way for to register the standby with the master so that
> the master knows it's out there, and still needs the logs, even when
> it's not connected.
I propose the new GUC replication_reserved_segments (better name?) which
determines the maximum number of WAL files held for the standby.
Design:
* Only the WAL files which are replication_reserved_segments segments older than the current write segment can be
recycled.IOW, we can think that the standby which falls replication_reserved_segments segments behind is always
connectedto the primary, and the WAL files needed for the active standby are not recycled.
* Disjoin the standby which falls more than replication_reserved_segment segments behind, in order to avoid the disk
fullfailure, i.e., the primary server's PANIC error. This would be only possible in asynchronous replication case.
Thought?
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center