Re: [COMMITTERS] pgsql: Reduce the number of semaphores used under --disable-spinlocks.
От | Robert Haas |
---|---|
Тема | Re: [COMMITTERS] pgsql: Reduce the number of semaphores used under --disable-spinlocks. |
Дата | |
Msg-id | CA+TgmoY=OTwGJyo3LH=J3iZhjU6E7wRn_tm1vJMKytCBRQu6xw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [COMMITTERS] pgsql: Reduce the number of semaphores used under --disable-spinlocks. (Andres Freund <andres@2ndquadrant.com>) |
Список | pgsql-hackers |
On Wed, Jun 18, 2014 at 3:56 PM, Andres Freund <andres@2ndquadrant.com> wrote: >> > I'm looking at the way you did this in the context of the atomics >> > patch. Won't: >> > s_init_lock_sema(volatile slock_t *lock) >> > { >> > static int counter = 0; >> > >> > *lock = (++counter) % NUM_SPINLOCK_SEMAPHORES; >> > } >> > >> > lead to bad results if spinlocks are intialized after startup? >> >> Why? > > Because every further process will start with a copy of the postmaster's > counter or with 0 (EXEC_BACKEND)? Oh, true. Maybe we should randomize that. >> > Essentially mapping new spinlocks to the same semaphore? >> >> Yeah, but so what? If we're mapping a bajillion spinlocks to the same >> semaphore already, what's a few more? > > Well, imagine something like parallel query creating new segments, > including a spinlock (possibly via a lwlock) at runtime. If there were > several backends processing such queries this they'd all map to the same > semaphore. Yeah. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: