On Sat, Dec 19, 2009 at 1:03 AM, Heikki Linnakangas <heikki.linnakan...@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 connected to 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 full failure, 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
