> > > > Synchronous(synchronous_commit = on) mode offers the ability to
> > > confirm WAL have been streamed in the same way as synchronous
> > > replication.
> > > > If an output is used as a different disk from the directory where
> > > > the
> > > transaction log should be stored.
> > > > Prevent the loss of data due to disk failure.
> > > >
> > > > the additional parameter(-m) and replicationslot specify, that its
> > > synchronous mode.
> > > > All received WAL write after, flush is executed and reply flush
> > > > position.
> > >
> > > What's the usecase for this? I can see some benefit in easier
> > > testing of syncrep, but that's basically it?
> >
> > When used with syncrep, standby server crashes, multiplexing of WAL
> can be collateral.
> > Data loss can be to nearly zero.
>
> I don't see how this gets pg_receivexlog much closer to a solution for
> multiplexing WAL. Since there's no support for streaming data, removing
> old WAL and such it seems to me you'd need to have something entirely
> different anyway?
> I'm not really averse to adding this feature (on the basis of easier
> syncrep testing alone), but I don't like the arguments for it so far...
The problems of multiplex WAL which I recognize as follows.
1.To flush multiple records per received consecutively. (implemented in pg_receivexlog)
2.A feedback message reports a flush position for every flush. (implemented in pg_receivexlog)
3.establishment of recovery steps by using pg_receivexlog.
4.removing old WAL.(Remove the recycled or archived WAL)
First, it is not considered multiple WAL.
I will post a patch to flush to multiple records for each received continuously.
By increasing the frequency of flush,
this patch reduces the lost of data of pg_receivexlog machine crash.
I will consider in turn also other problems.
Regards,
--
Furuya Osamu
