On Wed, Dec 23, 2009 at 2:49 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> (I don't fully understand your words above, sorry.)
NM ;-)
> Possibly an easier way would be to have a size limit, not a number of
> segments. Something like max_reserved_wal = 240GB. We made that change
> to shared_buffers a few years back and it was really useful.
For me, a size limit is intuitive because the checkpoint_segments which
is closely connected with the new parameter still indicates the number of
segments. But if more people like a size limit, I'll make that change.
> The problem I foresee is that doing it this way puts an upper limit on
> the size of database we can replicate. While we do base backup and
> transfer it we must store WAL somewhere. Forcing us to store the WAL on
> the master while this happens could be very limiting.
Yes. If the size of pg_xlog is relatively small to the size of database,
the primary would not be able to hold all the WAL files required for
the standby, so we would need to use the restore_command which
retrieves the WAL files from the master's archival area. I'm OK that
such extra operation is required in that special case, now.
>> * 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.
>
> Or at the start of replication.
Yes. I think that avoidance of the primary's PANIC error should be
given priority over a smooth start of replication.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
