On Fri, Sep 14, 2018 at 4:27 PM, 李海龙 <hailong.li@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