| From: | Amul Sul <sulamul(at)gmail(dot)com> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: [Patch] ALTER SYSTEM READ ONLY |
| Date: | 2020-11-20 17:43:22 |
| Message-ID: | CAAJ_b96MS2WwoKFJbvP55_XqTOQqUWJo_Zi08EfsfnqQ0USvsw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, 20 Nov 2020 at 9:53 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Thu, Oct 8, 2020 at 6:23 AM Amul Sul <sulamul(at)gmail(dot)com> wrote:
> > On a quick look at the latest 0001 patch, the following hunk to reset
> leftover
> > flags seems to be unnecessary:
> >
> > + /*
> > + * If some barrier types were not successfully absorbed, we will have
> > + * to try again later.
> > + */
> > + if (!success)
> > + {
> > + ResetProcSignalBarrierBits(flags);
> > + return;
> > + }
> >
> > When the ProcessBarrierPlaceholder() function returns false without an
> error,
> > that barrier flag gets reset within the while loop. The case when it
> has an
> > error, the rest of the flags get reset in the catch block. Correct me
> if I am
> > missing something here.
>
> Good catch. I think you're right. Do you want to update accordingly?
Sure, Ill update that. Thanks for the confirmation.
> Andres, do you like the new loop better?
>
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Щекин Ярослав | 2020-11-20 17:51:12 | Re: Probable documentation errors or improvements |
| Previous Message | Matthias van de Meent | 2020-11-20 17:32:44 | [patch] CLUSTER blocks scanned progress reporting |