Re: Backpatch b61d161c14 (Introduce vacuum errcontext ...)

From: Andres Freund <andres(at)anarazel(dot)de>
To: Justin Pryzby <pryzby(at)telsasoft(dot)com>
Cc: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Backpatch b61d161c14 (Introduce vacuum errcontext ...)
Date: 2020-06-22 20:57:12
Message-ID: 20200622205712.kgnxpkrebc4g2con@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2020-06-22 15:43:11 -0500, Justin Pryzby wrote:
> On Mon, Jun 22, 2020 at 01:09:39PM -0700, Andres Freund wrote:
> > I'm also uncomfortable with the approach of just copying all of
> > LVRelStats in several places:
> >
> > > /*
> > > @@ -1580,9 +1648,15 @@ lazy_vacuum_page(Relation onerel, BlockNumber blkno, Buffer buffer,
> > > int uncnt = 0;
> > > TransactionId visibility_cutoff_xid;
> > > bool all_frozen;
> > > + LVRelStats olderrinfo;
>
> I guess the alternative is to write like
>
> LVRelStats olderrinfo = {
> .phase = vacrelstats.phase,
> .blkno = vacrelstats.blkno,
> .indname = vacrelstats.indname,
> };

No, I don't think that's a solution. I think it's wrong to have
something like olderrinfo in the first place. Using a struct with ~25
members to store the current state of three variables just doesn't make
sense. Why isn't this just a LVSavedPosition struct or something like
that?

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2020-06-22 21:52:21 Re: Parallel Seq Scan vs kernel read ahead
Previous Message Andres Freund 2020-06-22 20:53:16 Re: [HACKERS] Custom compression methods