Horton

Re: Is Recovery actually paused?

Dilip Kumar <dilipbalaut@gmail.com>

View thread View on postgr.es
From: Dilip Kumar <dilipbalaut@gmail.com>
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>, Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>, Yugo Nagata <nagata@sraoss.co.jp>, Masahiko Sawada <sawada.mshk@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Simon Riggs <simon@2ndquadrant.com>
Date: 2021-02-24T14:51:32Z
Lists: pgsql-hackers

Attachments

On Wed, Feb 24, 2021 at 3:25 PM Dilip Kumar <dilipbalaut@gmail.com> wrote:
>

> > > > The reason for the checkpoint is to move to "paused" state in a
> > > > reasonable time.  I think we need to mention that reason rather than
> > > > what is done here.
> > >
> > > I will do that.

I have fixed this.

> > > >
> > > > +       /* get the recovery pause state */
> > > > +       switch(GetRecoveryPauseState())
> > > > +       {
> > > > +               case RECOVERY_NOT_PAUSED:
> > > > +                       state = "not paused";
> > > > +                       break;
> > > > ...
> > > > +               default:
> > > > +                       elog(ERROR, "invalid recovery pause state");

>
> I think for such cases IMHO the preferred style for PostgreSQL is that
> we add Assert(0) in the default case,  at least it appeared to me that
> way.

Added an Assert(0) in default case.

-- 
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com

Commits

  1. Be clear about whether a recovery pause has taken effect.

  2. Pause recovery for insufficient parameter settings

  3. Remove most volatile qualifiers from xlog.c