Thank you for the comment. At Thu, 2 Feb 2017 01:26:03 +0900, Fujii Masao <masao.fu...@gmail.com> wrote in <CAHGQGwEET=QBA_jND=xhrxn+9zrep4_qmbaqsbzg56beqxb...@mail.gmail.com> > > The attached patch does that. Usually it reads page headers only > > on segment boundaries, but once continuation record found (or > > failed to read the next page header, that is, the first record on > > the first page in the next segment has not been replicated), it > > becomes to happen on every page boundary until non-continuation > > page comes. > > I'm afraid that many WAL segments would start with a continuation record > when there are the workload of short transactions (e.g., by pgbench), and > which would make restart_lsn go behind very much. No?
I agreed. So trying to release the lock for every page boundary but restart_lsn goes behind much if so many contiguous pages were CONTRECORD. But I think the chance for the situation sticks for one or more segments is ignorablly low. Being said that, there *is* possibility of false continuation, anyway. > The discussion on this thread just makes me think that restart_lsn should > indicate the replay location instead of flush location. This seems safer. Standby restarts from minRecoveryPoint, which is a copy of XLogCtl->replayEndRecPtr and updated by UpdateMinRecoveryPoint(). Whlie, applyPtr in reply messages is a copy of XLogCtl->lastReplayedEndRecptr which is updated after the upate of on-disk minRecoveryPoint. It seems safe from the viewpoint. On the other hand, apply is pausable. Records are copied and flushd on standby then the segments on master that is already sent are safely be removed even for the case. In spite of that, older segments on the master are kept from being removed during the pause. If applyPtr were used as restart_lsn, this could be another problem and this is sure to happen. I'm not sure how much possibility is there for several contiguous segments are full of contpages. But I think it's worse that apply pause causes needless pg_wal flooding. regards, -- Kyotaro Horiguchi NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
