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 |
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 |