Re: Refactoring backend fork+exec code

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Refactoring backend fork+exec code
Дата
Msg-id 20240123195009.44wtutga24p5sh3s@awork3.anarazel.de
обсуждение исходный текст
Ответ на Re: Refactoring backend fork+exec code  (Heikki Linnakangas <hlinnaka@iki.fi>)
Ответы Re: Refactoring backend fork+exec code  (Heikki Linnakangas <hlinnaka@iki.fi>)
Список pgsql-hackers
Hi,

On 2024-01-23 21:07:08 +0200, Heikki Linnakangas wrote:
> On 22/01/2024 23:07, Andres Freund wrote:
> > > diff --git a/src/backend/utils/activity/backend_status.c b/src/backend/utils/activity/backend_status.c
> > > index 1a1050c8da1..92f24db4e18 100644
> > > --- a/src/backend/utils/activity/backend_status.c
> > > +++ b/src/backend/utils/activity/backend_status.c
> > > @@ -257,17 +257,16 @@ pgstat_beinit(void)
> > >       else
> > >       {
> > >           /* Must be an auxiliary process */
> > > -        Assert(MyAuxProcType != NotAnAuxProcess);
> > > +        Assert(IsAuxProcess(MyBackendType));
> > >           /*
> > >            * Assign the MyBEEntry for an auxiliary process.  Since it doesn't
> > >            * have a BackendId, the slot is statically allocated based on the
> > > -         * auxiliary process type (MyAuxProcType).  Backends use slots indexed
> > > -         * in the range from 0 to MaxBackends (exclusive), so we use
> > > -         * MaxBackends + AuxProcType as the index of the slot for an auxiliary
> > > -         * process.
> > > +         * auxiliary process type.  Backends use slots indexed in the range
> > > +         * from 0 to MaxBackends (exclusive), and aux processes use the slots
> > > +         * after that.
> > >            */
> > > -        MyBEEntry = &BackendStatusArray[MaxBackends + MyAuxProcType];
> > > +        MyBEEntry = &BackendStatusArray[MaxBackends + MyBackendType - FIRST_AUX_PROC];
> > >       }
> > 
> > Hm, this seems less than pretty. It's probably ok for now, but it seems like a
> > better fix might be to just start assigning backend ids to aux procs or switch
> > to indexing by pgprocno?
> 
> Using pgprocno is a good idea. Come to think of it, why do we even have a
> concept of backend ID that's separate from pgprocno? backend ID is used to
> index the ProcState array, but AFAICS we could use pgprocno as the index to
> that, too.

I think we should do that. There are a few processes not participating in
sinval, but it doesn't make enough of a difference to make sinval slower. And
I think there'd be far bigger efficiency improvements to sinvaladt than not
having a handful more entries.

Greetings,

Andres Freund



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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Remove pthread_is_threaded_np() checks in postmaster
Следующее
От: Andres Freund
Дата:
Сообщение: Re: the s_lock_stuck on perform_spin_delay