Re: Synchronous Log Shipping Replication - Mailing list pgsql-hackers

On Sat, 2008-09-06 at 22:09 -0400, Bruce Momjian wrote:
> Markus Wanner wrote:
> > > Hook for WALSender
> > > ------------------
> > > This hook is for introducing WALSender. There are the following
> > > three ideas of how to introduce WALSender. A required hook
> > > differs by which idea is adopted.
> > > 
> > > a) Use WALWriter as WALSender
> > > 
> > >    This idea needs WALWriter hook which intercepts WALWriter
> > >    literally. WALWriter stops the local WAL write and focuses on
> > >    WAL sending. This idea is very simple, but I don't think of
> > >    the use of WALWriter hook other than WAL sending.
> 
> The problem with this approach is that you are not sending WAL to the
> disk _while_ you are, in parallel, sending WAL to the slave;  I think
> this is useful for performance reasons in synrchonous replication.

Agreed

> > > b) Use new background process as WALSender
> > > 
> > >    This idea needs background-process hook which enables users
> > >    to define new background processes. I think the design of this
> > >    hook resembles that of rmgr hook proposed by Simon. I define
> > >    the table like RmgrTable. It's for registering some functions
> > >    (e.g. main function and exit...) for operating a background
> > >    process. Postmaster calls the function from the table suitably,
> > >    and manages a start and end of background process. ISTM that
> > >    there are many uses in this hook, e.g. performance monitoring
> > >    process like statspack.
> 
> I think starting/stopping a process for each WAL send is too much
> overhead.

I would agree with that, but I don't think that was being suggested was
it? See later.

> > > c) Use one backend as WALSender
> > > 
> > >    In this idea, slave calls the user-defined function which
> > >    takes charge of WAL sending via SQL e.g. "SELECT pg_walsender()".
> > >    Compared with other ideas, it's easy to implement WALSender
> > >    because postmater handles the establishment and authentication
> > >    of connection. But, this SQL causes a long transaction which
> > >    prevents vacuum. So, this idea needs idle-state hook which
> > >    executes plugin before transaction starts. I don't think of
> > >    the use of this hook other than WAL sending either.
> > 
> > The above cited wiki page sounds like you've already decided for b).
> 
> I assumed that there would be a background process like bgwriter that
> would be notified during a commit and send the appropriate WAL files to
> the slave.

ISTM that this last paragraph is actually what was meant by option b). 

I think it would work the other way around though, the WALSender would
send continuously and backends may choose to wait for it to reach a
certain LSN, or not. WALWriter really should work this way too.

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