On Fri, Sep 14, 2018 at 4:27 PM, 李海龙 <hailong...@qunar.com> wrote: > > HI, Dear pgsql-hackers > > > The details are as follows: > > > Environment: > > OS: CentOS 6.7 (Final), Linux 3.18.48-11.el6.x86_64 x86_64, 64-bit > > > PostgreSQL: > > postgres=# select version(); > version > --------------------------------------------------------------------------------------------------------- > PostgreSQL 10.5 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.4.7 > 20120313 (Red Hat 4.4.7-16), 64-bit > (1 row) > > postgres=# show wal_level ; > wal_level > ----------- > replica > (1 row) > > > When I enable the parameter track_commit_timestamp in postgresql.conf of a > Base Backup (making a Base Backup from a standby and the > track_commit_timestamp is off on it), >
In addition to the above operation, I've reproduced this issue by replaying a commit WAL record that sets the timestamp to a new page during the crash recovery (or from restart). It seems to me that the cause of this is that we could not extend commitTs page since the COMMIT_TS_ZEROPAGE WAL wasn't generated at the standby server whose track_commit_timestamp is off. So during replaying the commit WAL record the startup process fails since the corresponding commitTs page doesn't exist. To fix that maybe we can disable commitTs if controlFile->track_commit_timestamp == false and the track_commit_timestamp == true even in crash recovery. Regards, -- Masahiko Sawada NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center
