Re: Is Recovery actually paused?

From: Dilip Kumar <dilipbalaut(at)gmail(dot)com>
To: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Simon Riggs <simon(at)2ndquadrant(dot)com>
Subject: Re: Is Recovery actually paused?
Date: 2021-02-25 04:19:15
Message-ID: CAFiTN-uozX0Aa0pTvmuw8tNcndfwiMypPE-E1jhYHbgXR0Qzpg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Feb 25, 2021 at 6:52 AM Kyotaro Horiguchi
<horikyota(dot)ntt(at)gmail(dot)com> wrote:

> Recently we have mildly changed to the direction to utilize the
> compiler warning about enum coverage in switch struct. (Maybe we need
> another compiler option that enables that check for switch'es with the
> default case, though.) In that light, the direction is a switch
> without the default case then Assert if none of the cases is stepped
> on. This is what apply_dispatch does. Slightly different version of
> the same would be the following. This is more natural than the above.
>
> statestr = NULL;
> swtich(state)
> {
> case RECOVERY_NOT_PAUSED:
> statestr = "not paused";
> break;
> ...
> }
>
> Assert (statestr != NULL);
> return cstring_to_text(statestr);
>
> If the enum had many (more than ten or so?) values and it didn't seem
> stable I push that a bit strongly but it actually consists of only
> three values and not likely to get further values. So I don't insist
> on the style so strongly here.
>

Changed as per the suggestion.

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

Attachment Content-Type Size
v16-0001-Provide-a-new-interface-to-get-the-recovery-paus.patch text/x-patch 13.1 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2021-02-25 04:42:15 Re: 64-bit XIDs in deleted nbtree pages
Previous Message Justin Pryzby 2021-02-25 04:13:52 Re: 64-bit XIDs in deleted nbtree pages