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

From Alvaro Herrera
Subject Re: error context for vacuum to include block number
Date
Msg-id 20200326224951.GA20085@alvherre.pgsql
Whole thread Raw
In response to Re: error context for vacuum to include block number  (Justin Pryzby <pryzby@telsasoft.com>)
Responses Re: error context for vacuum to include block number  (Justin Pryzby <pryzby@telsasoft.com>)
List pgsql-hackers
On 2020-Mar-26, Justin Pryzby wrote:

> On Thu, Mar 26, 2020 at 10:04:57AM -0500, Justin Pryzby wrote:

> > And I think you're right: we only save state when the calling function has a
> > indname=NULL, so we never "put back" a non-NULL indname.  We go from having a
> > indname=NULL at lazy_scan_heap to not not-NULL at lazy_vacuum_index, and never
> > the other way around.
> 
> I removed the free_oldindname argument.

Hah, I was wondering about that free_oldindname business this morning as
well.

> > ... So once we've "reverted back", 1) the pointer is null; and, 2)
> > the callback function doesn't access it for the previous/reverted
> > phase anyway.

BTW I'm pretty sure this "revert back" phrasing is not good English --
you should just use "revert".  Maybe get some native speaker's opinion
on it.

And speaking of language, I find the particle "cbarg" rather very ugly,
and it's *everywhere* -- function name, function argument, local
variable, enum values, enum name.  It even spread to the typedefs.list
file!  Is this a new virus???  Put some soap in it!  Can't we use "info"
or "state" or something similar, less infectious, instead?

Thanks

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



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: [Patch] pg_rewind: options to use restore_command fromrecovery.conf or command line
Next
From: Mike Palmiotto
Date:
Subject: Re: Auxiliary Processes and MyAuxProc