Re: error context for vacuum to include block number
Masahiko Sawada <masahiko.sawada@2ndquadrant.com>
From: Masahiko Sawada <masahiko.sawada@2ndquadrant.com>
To: Justin Pryzby <pryzby@telsasoft.com>
Cc: Andres Freund <andres@anarazel.de>, Michael Paquier <michael@paquier.xyz>, Alvaro Herrera <alvherre@2ndquadrant.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2020-01-21T06:11:35Z
Lists: pgsql-hackers
On Tue, 21 Jan 2020 at 06:49, Justin Pryzby <pryzby@telsasoft.com> wrote: > > On Mon, Jan 20, 2020 at 11:11:20AM -0800, Andres Freund wrote: > > This I do not get. I didn't yet fully wake up, so I might just be slow? > > It was needlessly cute at the cost of clarity (meant to avoid setting > error_context_stack in lazy_scan_heap and again immediately on its return). > > On Mon, Jan 20, 2020 at 11:13:05AM -0800, Andres Freund wrote: > > I was thinking that you could just use LVRelStats. > > Done. > > On Mon, Jan 20, 2020 at 11:11:20AM -0800, Andres Freund wrote: > > Alternatively we could push another context for each index inside > > lazy_vacuum_all_indexes(). There's been plenty bugs in indexes > > triggering problems, so that could be worthwhile. > > Did this too, although I'm not sure what kind of errors it'd find (?) > > I considered elimating other uses of RelationGetRelationName, or looping over > vacrelstats->blkno instead of local blkno. I did that in an additional patch > (that will cause conflicts if you try to apply it, due to other vacuum patch in > this branch). > > CREATE TABLE t AS SELECT generate_series(1,99999)a; > > postgres=# SET client_min_messages=debug;SET statement_timeout=39; VACUUM (VERBOSE, PARALLEL 0) t; > INFO: vacuuming "public.t" > 2020-01-20 15:46:14.993 CST [20056] ERROR: canceling statement due to statement timeout > 2020-01-20 15:46:14.993 CST [20056] CONTEXT: while scanning block 211 of relation "public.t" > 2020-01-20 15:46:14.993 CST [20056] STATEMENT: VACUUM (VERBOSE, PARALLEL 0) t; > ERROR: canceling statement due to statement timeout > CONTEXT: while scanning block 211 of relation "public.t" > > SELECT 'CREATE INDEX ON t(a)' FROM generate_series(1,11);\gexec > UPDATE t SET a=a+1; > > postgres=# SET client_min_messages=debug;SET statement_timeout=99; VACUUM (VERBOSE, PARALLEL 0) t; > INFO: vacuuming "public.t" > DEBUG: "t_a_idx": vacuuming index > 2020-01-20 15:47:36.338 CST [20139] ERROR: canceling statement due to statement timeout > 2020-01-20 15:47:36.338 CST [20139] CONTEXT: while vacuuming relation "public.t_a_idx" > 2020-01-20 15:47:36.338 CST [20139] STATEMENT: VACUUM (VERBOSE, PARALLEL 0) t; > ERROR: canceling statement due to statement timeout > CONTEXT: while vacuuming relation "public.t_a_idx" > > I haven't found a good way of exercizing the "vacuuming heap" path, though. Some of them conflicts with the current HEAD(62c9b52231). Please rebase them. Regards, -- Masahiko Sawada http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Commits
-
Avoid calls to RelationGetRelationName() and RelationGetNamespace() in
- ef75140fe756 13.0 landed
-
Introduce vacuum errcontext to display additional information.
- b61d161c1463 13.0 landed
-
Fix mesurement of elapsed time during truncating heap in VACUUM.
- 007491979461 13.0 cited
-
Allow vacuum command to process indexes in parallel.
- 40d964ec997f 13.0 cited
-
Refactor code dedicated to index vacuuming in vacuumlazy.c
- 1ab41a3c8edc 13.0 landed
-
Remove duplicated progress reporting during heap scan of VACUUM
- e5a02e0fc68b 13.0 landed