From: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
---|---|
To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Masahiko Sawada <masahiko(dot)sawada(at)2ndquadrant(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Michael Paquier <michael(at)paquier(dot)xyz>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: error context for vacuum to include block number |
Date: | 2020-03-30 16:26:16 |
Message-ID: | 20200330162616.GP20103@telsasoft.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Mar 30, 2020 at 02:31:53PM +0530, Amit Kapila wrote:
> Now that the main patch is committed, I have reviewed the other two patches.
Thanks for that
On Mon, Mar 30, 2020 at 02:31:53PM +0530, Amit Kapila wrote:
> The v37-0003-Avoid-some-calls-to-RelationGetRelationName.patch looks
> good to me. I have added the commit message in the patch.
I realized the 0003 patch has an error in lazy_vacuum_index; it should be:
- RelationGetRelationName(indrel),
+ vacrelstats->indname,
That was maybe due to originally using a separate errinfo for each phase, with
one "char *relname" and no "char *indrel".
> I don't think the above change is correct. How will vacrelstats have
> correct values when vacuum_one_index is called via parallel workers
> (via parallel_vacuum_main)?
You're right: parallel main's vacrelstats was added by this patchset and only
the error context fields were initialized. I fixed it up in the attached by
also setting vacrelstats->new_rel_tuples and old_live_tuples. It's not clear
if this is worth it just to save an argument to two functions?
--
Justin
Attachment | Content-Type | Size |
---|---|---|
v39-0001-Avoid-some-calls-to-RelationGetRelationName.patch | text/x-diff | 3.7 KB |
v39-0002-Drop-reltuples.patch | text/x-diff | 4.8 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Vik Fearing | 2020-03-30 16:32:16 | Re: Error on failed COMMIT |
Previous Message | Tom Lane | 2020-03-30 16:24:06 | Re: snapper vs. HEAD |