WAL recycle retading based on active sync rep.

Hello.

We had too-early WAL recycling during a test we had on a sync
replication set. This is not a bug and a bit extreme case but is
contrary to expectation on synchronous replication.

> FATAL: could not receive data from WAL stream: ERROR: requested WAL segment 000000010000000000000088 has already been removed

This is because sync replication doesn't wait non-commit WALs to
be replicated. This situation is artificially caused with the
first patch attached and the following steps.

- Configure a master with max_wal_size=80MB and
min_wal_size=48MB, and synchronous_standby_names='*' then run.

- Configure a replica using pg_basebackup and run it.
Make a file /tmp/slow to delay replication.

- On the master do
=# create table t (a int);
=# insert into t (select * from generate_series(0, 2000000));

I could guess the following two approaches for this.

A. Retard wal recycling back to where sync replication reached.

B. Block wal insertion until sync replication reaches to the
first surviving segments.

The second attached patch implements the first measure. It makes
CreateCheckPoint consider satisfied sync replication on WAL
recycling. If WAL segments to be recycled is required by the
currently satisfied sync-replication, it keeps the required
segments and emit the following message.

> WARNING: sync replication too retarded. 2 extra WAL segments are preserved (last segno to preserve is moved from 185 to 183)
> HINT: If you see this message too frequently, consider increasing wal_keep_segments or max_wal_size.

This is somewhat simliar to what repl-slot does but this doesn't
anything when synchronous replication is not satisfied. Perhaps
max_temporary_preserve_segments or similar GUC is required to
limit amount of extra segments.

- Is this situation required to be saved? This is caused by a
large transaction, spans over two max_wal_size segments, or
replication stall lasts for a chackepoint period.

- Is the measure acceptable? For the worst case, a master
crashes from WAL space exhaustion. (But such large transaction
won't/shouldn't exist?)

Or other comments?

regards,

--
Kyotaro Horiguchi
NTT Open Source Software Center