Re: Sync Rep: First Thoughts on Code

On Thu, 2008-12-04 at 16:10 +0900, Fujii Masao wrote:

> > * Diagram on p.2 has two Archives. We have just one (yes)
> 
> No, we need archive in both the primary and standby. The primary needs
> archive because a base backup is required when starting the standby.
> Meanwhile, the standby needs archive for cooperating with pg_standby.
> 
> If the directory where pg_standby checks is the same as the directory
> where walreceiver writes the WAL, the halfway WAL file might be
> restored by pg_standby, and continuous recovery would fail. So, we have
> to separate the directories, and I assigned pg_xlog and archive to them.
> 
> Another idea; walreceiver writes the WAL to the file with temporary name,
> and rename it to the formal name when it fills. So, pg_standby doesn't
> restore a halfway WAL file. But it's more difficult to perform the failover
> because the unrenamed WAL file remains.

WAL sending is either via archiver or via streaming. We must switch
cleanly from one mode to the other and not half-way through a WAL file.

When WAL sending is about to begin, issue xlog switch. Then tell
archiver to shutdown once it has got to the last file. All files after
that point are streamed. So there need be no conflict in filename.

We must avoid having two archives, because people will configure this
incorrectly.

> > * If we have synchronous_commit = off do we ignore
> > synchronous_replication = on (yes)
> 
> No, we can configure them independently. synchronous_commit covers
> only local writing of the WAL. If synch_*commit* should cover both local
> writing and replication, I'd like to add new GUC which covers only local
> writing (synchronous_local_write?).

The only sensible settings are
synchronous_commit = on, synchronous_replication = on
synchronous_commit = on, synchronous_replication = off
synchronous_commit = off, synchronous_replication = off

This doesn't make any sense: (does it??)
synchronous_commit = off, synchronous_replication = on

> > Do we definitely need the archiver to move the files written by
> > walreceiver to archive and then move them back out again?
> 
> Yes, it's because of cooperating with pg_standby.

It seems very easy to make this happen the way we want. We could make
pg_standby look into pg_xlog also, for example.

I was expecting you to have walreceiver and startup share an end of WAL
address via shared memory, so that startup never tries to read past end.
That way we would be able to begin reading a WAL file *before* it was
filled. Waiting until a file fills means we still have to have
archive_timeout set to ensure we switch regularly.

We need the existing mechanisms for the start of replication (base
backup etc..) but we don't need them after that point.

-- Simon Riggs           www.2ndQuadrant.comPostgreSQL Training, Services and Support