From: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: error context for vacuum to include block number |
Date: | 2020-01-20 21:49:29 |
Message-ID: | 20200120214929.GV26045@telsasoft.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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 | Content-Type | Size |
---|---|---|
v10-0001-vacuum-errcontext-to-show-block-being-processed.patch | text/x-diff | 4.0 KB |
v10-0002-add-errcontext-callback-in-lazy_vacuum_heap-too.patch | text/x-diff | 2.0 KB |
v10-0003-Add-vacrelstats.stage-and-distinct-context-messa.patch | text/x-diff | 2.1 KB |
v10-0004-errcontext-for-lazy_vacuum_index.patch | text/x-diff | 2.4 KB |
v10-0005-Avoid-extra-calls-like-GetRelationName.patch | text/x-diff | 8.1 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Egor Rogov | 2020-01-20 23:07:17 | Re: BRIN cost estimate breaks geometric indexes |
Previous Message | David Fetter | 2020-01-20 21:39:23 | Re: Increase psql's password buffer size |