Re: Index maintenance function for BRIN doesn't checkRecoveryInProgress()
От | Alvaro Herrera |
---|---|
Тема | Re: Index maintenance function for BRIN doesn't checkRecoveryInProgress() |
Дата | |
Msg-id | 20180613145106.nmfubbdoftxncbto@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: Index maintenance function for BRIN doesn't check RecoveryInProgress() (Alexander Korotkov <a.korotkov@postgrespro.ru>) |
Ответы |
Re: Index maintenance function for BRIN doesn't check RecoveryInProgress()
|
Список | pgsql-hackers |
On 2018-Jun-13, Alexander Korotkov wrote: > On Wed, Jun 13, 2018 at 12:48 PM Kuntal Ghosh > <kuntalghosh.2007@gmail.com> wrote: > > On Wed, Jun 13, 2018 at 2:28 PM, Masahiko Sawada <sawada.mshk@gmail.com> 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
В списке pgsql-hackers по дате отправления: