Date: Tue, 3 Mar 2020 16:49:00 -0300
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Justin Pryzby <pryzby@telsasoft.com>
Cc: Masahiko Sawada <masahiko.sawada@2ndquadrant.com>,
	Andres Freund <andres@anarazel.de>,
	Michael Paquier <michael@paquier.xyz>, pgsql-hackers@postgresql.org
Subject: Re: error context for vacuum to include block number
Message-ID: <20200303194900.GA17197@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20200303193205.GG684@telsasoft.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Precedence: bulk

On 2020-Mar-03, Justin Pryzby wrote:

> On Thu, Feb 27, 2020 at 09:09:42PM -0300, Alvaro Herrera wrote:
> > > +		case PROGRESS_VACUUM_PHASE_VACUUM_HEAP:
> > > +			if (BlockNumberIsValid(cbarg->blkno))
> > > +				errcontext("while vacuuming block %u of relation \"%s.%s\"",
> > > +						cbarg->blkno, cbarg->relnamespace, cbarg->relname);
> > > +			break;
> > 
> > I think you should still call errcontext() when blkno is invalid.
> 
> In my experience while testing, the conditional avoids lots of CONTEXT noise
> from interrupted autovacuum, at least.  I couldn't easily reproduce it with the
> current patch, though, maybe due to less pushing and popping.

I think you're saying that the code had the bug that too many lines were
reported because of excessive stack pushes, and you worked around it by
making the errcontext() be conditional; and that now the bug is fixed by
avoiding the push/pop games -- which explains why you can no longer
reproduce it.  I don't see why you want to keep the no-longer-needed
workaround.


Your use of the progress-report enum now has two warts -- the "-1"
value, and this one,

> +#define PROGRESS_VACUUM_PHASE_VACUUM_FSM		7 /* For error reporting only */

I'd rather you define a new enum, in lazyvacuum.c.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services