On Sat, Mar 21, 2020 at 1:33 PM Justin Pryzby <pryzby@telsasoft.com> wrote:
>
> On Sat, Mar 21, 2020 at 01:00:03PM +0530, Amit Kapila wrote:
> > I have addressed your comments in the attached patch. Today, while
> > testing error messages from various phases, I noticed that the patch
> > fails to display error context if the error occurs during the truncate
> > phase. The reason was that we had popped the error stack in
> > lazy_scan_heap due to which it never calls the callback. I think we
> > need to set up callback at a higher level as is done in the attached
> > patch. I have done the testing by inducing errors in various phases
> > and it prints the required information. Let me know what you think of
> > the attached?
>
> Thanks. My tests with TRUNCATE were probably back when we had multiple
> push/pop cycles of local error callbacks.
>
> This passes my tests.
>
Today, I have done some additional testing with parallel workers and
it seems to display the appropriate errors. See below:
postgres=# create table t1(c1 int, c2 char(500), c3 char(500));
CREATE TABLE
postgres=# insert into t1 values(generate_series(1,300000),'aaaa', 'bbbb');
INSERT 0 300000
postgres=# delete from t1 where c1 > 200000;
DELETE 100000
postgres=# vacuum t1;
ERROR: Error induced during index vacuum
CONTEXT: while vacuuming index "idx_t1_c3" of relation "public.t1"
parallel worker
while vacuuming index "idx_t1_c2" of relation "public.t1"
Here, you can see that the index names displayed in two messages are
different, basically, the leader backend got the error generated in
worker when it was vacuuming the other index.
I have used the attached patch to induce error.
I think the patch is in good shape now and I am happy with it. We can
think of proceeding with this unless we want the further enhancement
for FSM which I am not sure is a good idea.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com