Hello, I've returned from my overseas trip for just over one week. # and I'll leave Japan again after this...
> > restorePtr <= replayPtr <= receivePtr > > > > But XLByteLT(recievePtr, replayPtr) this should not return true > > under the condition above.. Something wrong in my assumption? > > When walreceiver is not running, i.e., the startup process reads the WAL files > from the archival area, the replay location would get bigger than the > receive one. I've overlooked that startup process of the standby reads archives first, and then WAL. But the current patch enables progress governing based on checkpoint_segments during archive recovery on the standby. At Wed, 25 Apr 2012 02:20:37 +0900, Fujii Masao <masao.fu...@gmail.com> wrote in <cahgqgwfso5wfptnalxme-ozrqq6kk24xgtybvjjhdytjf9f...@mail.gmail.com> > To alleviate the above problem, at least we might have to > change the recovery logic so that the archived WAL files are > restored with a temporary name, if cascading replication is not > enabled (i.e., !standby_mode || !hot_standby || max_wal_senders > <= 0). Or we might have to remove the restored WAL file after > replaying it and before opening the next one, without waiting > for a restartpoint to remove the restored WAL files. Thought? I think it is beyond a bug fix. Furthermore, this is not a problem of speed of restartpoint progression, I suppose. If so, this should be cared as another problem. Putting aside the problem of vast amount of copied WALs, I suppose the remaining problem is needless restartpoint acceleration caused during archive restoration on the standby. I will try to resolve this problem. Is that OK? Thinking about the so-many-copied-WAL problem, IMHO, using temporary name only for non-cascading is not a good solution because it leads complication and retrogression to the code and behavior, nevertheless it won't solve the half of the problem. I don't yet understand about cascading replication enough, but I suppose erasing WALs as becoming out of use (by some logic I don't find yet) is hopeful. regards, -- Kyotaro Horiguchi NTT Open Source Software Center == My e-mail address has been changed since Apr. 1, 2012. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
