Re: pg_background (and more parallelism infrastructure patches)

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: pg_background (and more parallelism infrastructure patches)
Дата
Msg-id CAA4eK1KaCDBC3_yRLh521JYvLn6kGLWQbpc_jRERFLQUe5SnfQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: pg_background (and more parallelism infrastructure patches)  (Andres Freund <andres@2ndquadrant.com>)
Список pgsql-hackers
On Thu, Oct 9, 2014 at 4:02 AM, Andres Freund <andres@2ndquadrant.com> wrote:
>
> >  /*
> > + * Arrange to remove a dynamic shared memory mapping at cleanup time.
> > + *
> > + * dsm_keep_mapping() can be used to preserve a mapping for the entire
> > + * lifetime of a process; this function reverses that decision, making
> > + * the segment owned by the current resource owner.  This may be useful
> > + * just before performing some operation that will invalidate the segment
> > + * for future use by this backend.
> > + */
> > +void
> > +dsm_unkeep_mapping(dsm_segment *seg)
> > +{
> > +     Assert(seg->resowner == NULL);
> > +     ResourceOwnerEnlargeDSMs(CurrentResourceOwner);
> > +     seg->resowner = CurrentResourceOwner;
> > +     ResourceOwnerRememberDSM(seg->resowner, seg);
> > +}
>
> Hm, I dislike the name unkeep.

I also think function name is not appropriate as per functionality.

> I guess you want to be symmetric to
> dsm_keep_mapping? dsm_manage_mapping(), dsm_ensure_mapping_cleanup()
> dm_remember_mapping()?

Another could be dsm_change_mapping().  Yet another idea could
be that we use single function (dsm_manage_mapping() with an
additional parameter to indicate the scope of segment) instead of
two different functions dsm_keep_mapping() and
dsm_unkeep_mapping().


With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

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

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: Deferring some AtStart* allocations?
Следующее
От:
Дата:
Сообщение: Re: pg_receivexlog --status-interval add fsync feedback