> > > > 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
