Re: Rationalizing SInval/PGPROC data structures and locking

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: Rationalizing SInval/PGPROC data structures and locking
Дата
Msg-id 20050519004550.GC12557@surnet.cl
обсуждение исходный текст
Ответ на Rationalizing SInval/PGPROC data structures and locking  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Wed, May 18, 2005 at 08:16:47PM -0400, Tom Lane wrote:

> The reason things got this way is that we've been loading more and more
> functionality onto the array of PGPROC pointers that is, more or less
> incidentally, maintained by sinval.c.  I'm thinking that it'd be a good
> idea to remove most of that stuff from sinval.c and put it into a
> separate module that maintains its own array of PGPROC pointers with a
> separate lock.  There's no reason why, eg, GetSnapshotData needs to
> conflict with transfer of SI inval messages, which is what SInvalLock
> was originally designed to protect.

I agree this is a good idea.  I might mention that I was going to put
some things in the PGPROC array for MultiXactId, then saw that getting
the SInvalLock for operations on those would abuse the lock too much --
that's when I decided to move them to a separate struct.

-- 
Alvaro Herrera (<alvherre[a]surnet.cl>)
"In Europe they call me Niklaus Wirth; in the US they call me Nickel's worth.That's because in Europe they call me by
name,and in the US by value!"
 


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

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: Two-phase commit issues
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: Learning curves and such (was Re: pgFoundry)