From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
---|---|
To: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Backpatch b61d161c14 (Introduce vacuum errcontext ...) |
Date: | 2020-07-02 03:37:10 |
Message-ID: | CAA4eK1+KByqSZB6103taM06fD0NDFfXgK6Nc5yRQ-TyWYgW9zw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jun 30, 2020 at 9:30 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | John Naylor | 2020-07-02 03:57:47 | Re: Speedup usages of pg_*toa() functions |
Previous Message | Masahiko Sawada | 2020-07-02 03:30:47 | Re: Resetting spilled txn statistics in pg_stat_replication |