Re: when set track_commit_timestamp on, database system abort startup - Mailing list pgsql-hackers

From Masahiko Sawada
Subject Re: when set track_commit_timestamp on, database system abort startup
Date
Msg-id CAD21AoAB_TsWdBQy9hkaW2paWXRL7mtgWCqMekgHLwXeKTXMLw@mail.gmail.com
Whole thread Raw
In response to Re: when set track_commit_timestamp on, database system abort startup  (Michael Paquier <michael@paquier.xyz>)
Responses Re: when set track_commit_timestamp on, database system abort startup
List pgsql-hackers
On Tue, Sep 25, 2018 at 1:43 PM, Michael Paquier <michael@paquier.xyz> wrote:
> Sawada-san,
>
> On Mon, Sep 24, 2018 at 08:28:45AM +0900, Michael Paquier wrote:
>> Wouldn't it be better to incorporate the new test as part of
>> 004_restart.pl?  This way, we avoid initializing a full instance, which
>> is always a good thing as that's very costly.  The top of this file also
>> mentions that it tests clean restarts, but it bothers also about crash
>> recovery.
>
> I have been able to work on this bug, and rewrote the proposed test case
> as attached.  The test can only get on v11 and HEAD.  What do you think?

Thank you for working on this.

+
+# Start the server, which generates a XLOG_PARAMETER_CHANGE record where
+# the parameter change is registered.
 $node_master->start;

+# Now restart again the server so as no record XLOG_PARAMETER_CHANGE are
+# replayed with the follow-up immediate shutdown.
+$node_master->restart;

Can we use "XLOG_PARAMETER_CHANGE record" instead of  "record
XLOG_PARAMETER_CHANGE" at the second hunk because the comment of the
first hunk uses it. The other part of this patch looks good to me.

Regards,

--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center


pgsql-hackers by date:

Previous
From: Kevin Grittner
Date:
Subject: Re: [HACKERS] SERIALIZABLE on standby servers
Next
From: Noah Misch
Date:
Subject: Re: "could not reattach to shared memory" on buildfarm member dory