On 2018-Sep-15, Masahiko Sawada wrote:
> On Fri, Sep 14, 2018 at 4:27 PM, 李海龙 <hailong.li@qunar.com> wrote:
> > 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.
Hmm, wow. I wonder if it's possible to detect the config difference
early enough that the zeropage WAL records are emitted, instead. But
even this might not work, since some transactions need to have their
commitTS in pages that will not have been zeroed anyway, because the
page threshold was crossed in the old primary.
> To fix that maybe we can disable commitTs if
> controlFile->track_commit_timestamp == false and the
> track_commit_timestamp == true even in crash recovery.
Hmm, so keep it off while crash recovery runs, and once it's out of that
then enable it automatically? That might work -- by definition we don't
care about the commit TSs of the transaction replayed during crash
recovery, since they were executed in the primary that didn't have
commitTS enable anyway.
It seems like the first thing we need is TAP cases that reproduce these
two crash scenarios.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services