Re: error context for vacuum to include block number

From: Justin Pryzby <pryzby(at)telsasoft(dot)com>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Masahiko Sawada <masahiko(dot)sawada(at)2ndquadrant(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Michael Paquier <michael(at)paquier(dot)xyz>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: error context for vacuum to include block number
Date: 2020-02-27 21:08:13
Message-ID: 20200227210813.GC29456@telsasoft.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Feb 20, 2020 at 02:02:36PM -0300, Alvaro Herrera wrote:
> On 2020-Feb-19, Justin Pryzby wrote:
>
> > Also, I was thinking that lazy_scan_heap doesn't needs to do this:
> >
> > + /* Pop the error context stack while calling vacuum */
> > + error_context_stack = errcallback.previous;
> > ...
> > + /* Set the error context while continuing heap scan */
> > + error_context_stack = &errcallback;
> >
> > It seems to me that's not actually necessary, since lazy_vacuum_heap will just
> > *push* a context handler onto the stack, and then pop it back off.
>
> So if you don't pop before pushing, you'll end up with two context
> lines, right?

Hm, looks like you're right, but that's not what I intended (and I didn't hit
that in my test).

> I think it would make sense to
> initialize the context callback just *once* for a vacuum run, and from
> that point onwards, just update the errcbarg struct to match what
> you're currently doing -- not continually pop/push error callback stack
> entries. See below ...

Originally, the patch only supported "scanning heap", and set the callback
strictly, to avoid having callback installed when calling other functions (like
vacuuming heap/indexes).

Then incrementally added callbacks in increasing number of places. We only
need one errcontext. And possibly you're right that the callback could always
be in place (?). But what about things like vacuuming FSM ? I think we'd need
another "phase" for that (or else invent a PHASE_IGNORE to do nothing). Would
VACUUM_FSM be added to progress reporting, too? We're also talking about new
phase for TRUNCATE_PREFETCH and TRUNCATE_WAIT.

Regarding the cbarg, at one point I took a suggestion from Andres to use the
LVRelStats struct. I got rid of that since I didn't like sharing "blkno"
between heap scanning and heap vacuuming, and needs to be reset when switching
back to scanning heap. I experimented now going back to that now. The only
utility is in having an single allocation of relname/space.

--
Justin

Attachment Content-Type Size
v22-0001-vacuum-errcontext-to-show-block-being-processed.patch text/x-diff 12.9 KB
v22-0002-add-callback-for-truncation.patch text/x-diff 1.5 KB
v22-0003-Avoid-some-calls-to-RelationGetRelationName.patch text/x-diff 3.7 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2020-02-27 21:11:05 Re: Resolving the python 2 -> python 3 mess
Previous Message Jeff Davis 2020-02-27 21:01:08 Add LogicalTapeSetExtend() to logtape.c