Index maintenance function for BRIN doesn't check RecoveryInProgress()

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Index maintenance function for BRIN doesn't check RecoveryInProgress()

Masahiko Sawada
Hi,

Three functions: brin_summarize_new_values, brin_summarize_range and
brin_desummarize_range can be called during recovery as follows.

=# select brin_summarize_new_values('a_idx');
ERROR:  cannot acquire lock mode ShareUpdateExclusiveLock on database
objects while recovery is in progress
HINT:  Only RowExclusiveLock or less can be acquired on database
objects during recovery.

I think we should complaint "recovery is in progress" error in this
case rather than erroring due to lock modes.
Attached patch fixes them.

Regards,

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

brin_maintenance_func.patch (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Index maintenance function for BRIN doesn't check RecoveryInProgress()

Kuntal Ghosh
On Wed, Jun 13, 2018 at 2:28 PM, Masahiko Sawada <[hidden email]> wrote:

> Hi,
>
> Three functions: brin_summarize_new_values, brin_summarize_range and
> brin_desummarize_range can be called during recovery as follows.
>
> =# select brin_summarize_new_values('a_idx');
> ERROR:  cannot acquire lock mode ShareUpdateExclusiveLock on database
> objects while recovery is in progress
> HINT:  Only RowExclusiveLock or less can be acquired on database
> objects during recovery.
>
> I think we should complaint "recovery is in progress" error in this
> case rather than erroring due to lock modes.
+1



--
Thanks & Regards,
Kuntal Ghosh
EnterpriseDB: http://www.enterprisedb.com

Reply | Threaded
Open this post in threaded view
|

Re: Index maintenance function for BRIN doesn't check RecoveryInProgress()

Alexander Korotkov
On Wed, Jun 13, 2018 at 12:48 PM Kuntal Ghosh
<[hidden email]> wrote:

> On Wed, Jun 13, 2018 at 2:28 PM, Masahiko Sawada <[hidden email]> wrote:
> > Hi,
> >
> > Three functions: brin_summarize_new_values, brin_summarize_range and
> > brin_desummarize_range can be called during recovery as follows.
> >
> > =# select brin_summarize_new_values('a_idx');
> > ERROR:  cannot acquire lock mode ShareUpdateExclusiveLock on database
> > objects while recovery is in progress
> > HINT:  Only RowExclusiveLock or less can be acquired on database
> > objects during recovery.
> >
> > I think we should complaint "recovery is in progress" error in this
> > case rather than erroring due to lock modes.
> +1

+1,
but current behavior doesn't seem to be bug, but rather not precise
enough error reporting.  So, I think we shouldn't consider
backpatching this.

------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

Reply | Threaded
Open this post in threaded view
|

Re: Index maintenance function for BRIN doesn't check RecoveryInProgress()

Alvaro Herrera-9
On 2018-Jun-13, Alexander Korotkov wrote:

> On Wed, Jun 13, 2018 at 12:48 PM Kuntal Ghosh
> <[hidden email]> wrote:
> > On Wed, Jun 13, 2018 at 2:28 PM, Masahiko Sawada <[hidden email]> wrote:
> > > Hi,
> > >
> > > Three functions: brin_summarize_new_values, brin_summarize_range and
> > > brin_desummarize_range can be called during recovery as follows.
> > >
> > > =# select brin_summarize_new_values('a_idx');
> > > ERROR:  cannot acquire lock mode ShareUpdateExclusiveLock on database
> > > objects while recovery is in progress
> > > HINT:  Only RowExclusiveLock or less can be acquired on database
> > > objects during recovery.

Good catch!

> > > I think we should complaint "recovery is in progress" error in this
> > > case rather than erroring due to lock modes.
> > +1
>
> +1,
> but current behavior doesn't seem to be bug, but rather not precise
> enough error reporting.  So, I think we shouldn't consider
> backpatching this.

I guess you could go either way ... we're just changing one unhelpful
error with a better one: there is no change in behavior.  I would
backpatch this, myself, and avoid the code divergence.

--
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Reply | Threaded
Open this post in threaded view
|

Re: Index maintenance function for BRIN doesn't check RecoveryInProgress()

Simon Riggs
On 13 June 2018 at 15:51, Alvaro Herrera <[hidden email]> wrote:

> On 2018-Jun-13, Alexander Korotkov wrote:
>
>> On Wed, Jun 13, 2018 at 12:48 PM Kuntal Ghosh
>> <[hidden email]> wrote:
>> > On Wed, Jun 13, 2018 at 2:28 PM, Masahiko Sawada <[hidden email]> wrote:
>> > > Hi,
>> > >
>> > > Three functions: brin_summarize_new_values, brin_summarize_range and
>> > > brin_desummarize_range can be called during recovery as follows.
>> > >
>> > > =# select brin_summarize_new_values('a_idx');
>> > > ERROR:  cannot acquire lock mode ShareUpdateExclusiveLock on database
>> > > objects while recovery is in progress
>> > > HINT:  Only RowExclusiveLock or less can be acquired on database
>> > > objects during recovery.
>
> Good catch!
>
>> > > I think we should complaint "recovery is in progress" error in this
>> > > case rather than erroring due to lock modes.
>> > +1
>>
>> +1,
>> but current behavior doesn't seem to be bug, but rather not precise
>> enough error reporting.  So, I think we shouldn't consider
>> backpatching this.
>
> I guess you could go either way ... we're just changing one unhelpful
> error with a better one: there is no change in behavior.  I would
> backpatch this, myself, and avoid the code divergence.

WAL control functions all say the same thing, so we can do that here also.

I'd prefer it if the message was more generic, so remove the
summarization/desummarization wording from the message. i.e.
"BRIN control functions cannot be executed during recovery"

--
Simon Riggs                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Reply | Threaded
Open this post in threaded view
|

Re: Index maintenance function for BRIN doesn't check RecoveryInProgress()

Masahiko Sawada
On Thu, Jun 14, 2018 at 12:04 AM, Simon Riggs <[hidden email]> wrote:

> On 13 June 2018 at 15:51, Alvaro Herrera <[hidden email]> wrote:
>> On 2018-Jun-13, Alexander Korotkov wrote:
>>
>>> On Wed, Jun 13, 2018 at 12:48 PM Kuntal Ghosh
>>> <[hidden email]> wrote:
>>> > On Wed, Jun 13, 2018 at 2:28 PM, Masahiko Sawada <[hidden email]> wrote:
>>> > > Hi,
>>> > >
>>> > > Three functions: brin_summarize_new_values, brin_summarize_range and
>>> > > brin_desummarize_range can be called during recovery as follows.
>>> > >
>>> > > =# select brin_summarize_new_values('a_idx');
>>> > > ERROR:  cannot acquire lock mode ShareUpdateExclusiveLock on database
>>> > > objects while recovery is in progress
>>> > > HINT:  Only RowExclusiveLock or less can be acquired on database
>>> > > objects during recovery.
>>
>> Good catch!
>>
>>> > > I think we should complaint "recovery is in progress" error in this
>>> > > case rather than erroring due to lock modes.
>>> > +1
>>>
>>> +1,
>>> but current behavior doesn't seem to be bug, but rather not precise
>>> enough error reporting.  So, I think we shouldn't consider
>>> backpatching this.
>>
>> I guess you could go either way ... we're just changing one unhelpful
>> error with a better one: there is no change in behavior.  I would
>> backpatch this, myself, and avoid the code divergence.
>
> WAL control functions all say the same thing, so we can do that here also.
+1

> I'd prefer it if the message was more generic, so remove the
> summarization/desummarization wording from the message. i.e.
> "BRIN control functions cannot be executed during recovery"
>

Agreed. Attached an updated patch.

Regards,

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

brin_maintenance_func_v2.patch (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Index maintenance function for BRIN doesn't check RecoveryInProgress()

Michael Paquier-2
On Thu, Jun 14, 2018 at 02:06:57AM +0900, Masahiko Sawada wrote:
> On Thu, Jun 14, 2018 at 12:04 AM, Simon Riggs <[hidden email]> wrote:
>> On 13 June 2018 at 15:51, Alvaro Herrera <[hidden email]> wrote:
>>> I guess you could go either way ... we're just changing one unhelpful
>>> error with a better one: there is no change in behavior.  I would
>>> backpatch this, myself, and avoid the code divergence.
>>
>> WAL control functions all say the same thing, so we can do that here also.
>
> +1

+1 for a back-patch to v10.  The new error message brings clarity in my
opinion.
--
Michael

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Index maintenance function for BRIN doesn't check RecoveryInProgress()

Alvaro Herrera-9
On 2018-Jun-14, Michael Paquier wrote:

> On Thu, Jun 14, 2018 at 02:06:57AM +0900, Masahiko Sawada wrote:
> > On Thu, Jun 14, 2018 at 12:04 AM, Simon Riggs <[hidden email]> wrote:
> >> On 13 June 2018 at 15:51, Alvaro Herrera <[hidden email]> wrote:
> >>> I guess you could go either way ... we're just changing one unhelpful
> >>> error with a better one: there is no change in behavior.  I would
> >>> backpatch this, myself, and avoid the code divergence.
> >>
> >> WAL control functions all say the same thing, so we can do that here also.
> >
> > +1
>
> +1 for a back-patch to v10.  The new error message brings clarity in my
> opinion.

Pushed, backpatched to 9.5.  Thanks!

--
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Reply | Threaded
Open this post in threaded view
|

Re: Index maintenance function for BRIN doesn't check RecoveryInProgress()

Masahiko Sawada
On Fri, Jun 15, 2018 at 2:20 AM, Alvaro Herrera
<[hidden email]> wrote:

> On 2018-Jun-14, Michael Paquier wrote:
>
>> On Thu, Jun 14, 2018 at 02:06:57AM +0900, Masahiko Sawada wrote:
>> > On Thu, Jun 14, 2018 at 12:04 AM, Simon Riggs <[hidden email]> wrote:
>> >> On 13 June 2018 at 15:51, Alvaro Herrera <[hidden email]> wrote:
>> >>> I guess you could go either way ... we're just changing one unhelpful
>> >>> error with a better one: there is no change in behavior.  I would
>> >>> backpatch this, myself, and avoid the code divergence.
>> >>
>> >> WAL control functions all say the same thing, so we can do that here also.
>> >
>> > +1
>>
>> +1 for a back-patch to v10.  The new error message brings clarity in my
>> opinion.
>
> Pushed, backpatched to 9.5.  Thanks!
>

Thank you!

Regards,

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