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

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Backpatch b61d161c14 (Introduce vacuum errcontext ...)
Дата
Msg-id 20200622205712.kgnxpkrebc4g2con@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: Backpatch b61d161c14 (Introduce vacuum errcontext ...)  (Justin Pryzby <pryzby@telsasoft.com>)
Ответы Re: Backpatch b61d161c14 (Introduce vacuum errcontext ...)  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Backpatch b61d161c14 (Introduce vacuum errcontext ...)  (Justin Pryzby <pryzby@telsasoft.com>)
Список 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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: [HACKERS] Custom compression methods
Следующее
От: Thomas Munro
Дата:
Сообщение: Re: Parallel Seq Scan vs kernel read ahead