Re: error context for vacuum to include block number

Justin Pryzby <pryzby@telsasoft.com>

From: Justin Pryzby <pryzby@telsasoft.com>
To: Andres Freund <andres@anarazel.de>
Cc: Michael Paquier <michael@paquier.xyz>, Alvaro Herrera <alvherre@2ndquadrant.com>, pgsql-hackers@postgresql.org
Date: 2020-01-20T21:49:29Z
Lists: pgsql-hackers

Attachments

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.

Commits

  1. Avoid calls to RelationGetRelationName() and RelationGetNamespace() in

  2. Introduce vacuum errcontext to display additional information.

  3. Fix mesurement of elapsed time during truncating heap in VACUUM.

  4. Allow vacuum command to process indexes in parallel.

  5. Refactor code dedicated to index vacuuming in vacuumlazy.c

  6. Remove duplicated progress reporting during heap scan of VACUUM