On Sat, Mar 21, 2020 at 1:33 PM Justin Pryzby <pry...@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
induce_error_index.patch
Description: Binary data