Re: error context for vacuum to include block number - Mailing list pgsql-hackers

From Justin Pryzby
Subject Re: error context for vacuum to include block number
Date
Msg-id 20200120214929.GV26045@telsasoft.com
Whole thread Raw
In response to Re: error context for vacuum to include block number  (Andres Freund <andres@anarazel.de>)
Responses Re: error context for vacuum to include block number  (Masahiko Sawada <masahiko.sawada@2ndquadrant.com>)
Re: error context for vacuum to include block number  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
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.

Attachment

pgsql-hackers by date:

Previous
From: David Fetter
Date:
Subject: Re: Increase psql's password buffer size
Next
From: Egor Rogov
Date:
Subject: Re: BRIN cost estimate breaks geometric indexes