Re: Backpatch b61d161c14 (Introduce vacuum errcontext ...) - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Backpatch b61d161c14 (Introduce vacuum errcontext ...)
Date
Msg-id CAA4eK1+KByqSZB6103taM06fD0NDFfXgK6Nc5yRQ-TyWYgW9zw@mail.gmail.com
Whole thread Raw
In response to Re: Backpatch b61d161c14 (Introduce vacuum errcontext ...)  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: Backpatch b61d161c14 (Introduce vacuum errcontext ...)  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
On Tue, Jun 30, 2020 at 9:30 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> >
> > If I am not missing anything then that change was in
> > lazy_cleanup_index and after this patch, it won't be required because
> > we are using a different variable name.
> >
> > I have combined both the patches now.
> >
>
> I am planning to push this tomorrow if there are no further
> suggestions/comments.
>

Pushed.  Now, coming back to the question of the back patch.  I see a
point in deferring this for 3-6 months or maybe more after PG13 is
released.  OTOH, this implementation is mainly triggered by issues
reported in this area and this doesn't seem to be a very invasive
patch which can cause some de-stabilization in back-branches. I am not
in a hurry to get this backpatched but still, it would be good if this
can be backpatched earlier as quite a few people (onlist and EDB
customers) have reported issues that could have been narrowed down if
this patch is present in back-branches.

It seems Alvaro and I are in favor of backpatch whereas Andres and
Justin seem to think it should be deferred until this change has seen
some real-world exposure.

Anyone else wants to weigh in?

-- 
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: Resetting spilled txn statistics in pg_stat_replication
Next
From: John Naylor
Date:
Subject: Re: Speedup usages of pg_*toa() functions