Re: pgsql: Do all accesses to shared buffer headers
От
Neil Conway
Тема
Re: pgsql: Do all accesses to shared buffer headers
Дата
Msg-id
1129160190.8718.32.camel@localhost.localdomain
Ответ на
Список
Дерево обсуждения
pgsql: Do all accesses to shared buffer headers through tgl@svr1.postgresql.org (Tom Lane)
Re: pgsql: Do all accesses to shared buffer headers Neil Conway <neilc@samurai.com>
Re: pgsql: Do all accesses to shared buffer headers through Tom Lane <tgl@sss.pgh.pa.us>
Re: pgsql: Do all accesses to shared buffer headers Neil Conway <neilc@samurai.com>
Re: pgsql: Do all accesses to shared buffer headers through Tom Lane <tgl@sss.pgh.pa.us>
Re: pgsql: Do all accesses to shared buffer headers Tom Lane <tgl@sss.pgh.pa.us>
Re: pgsql: Do all accesses to shared buffer headers Neil Conway <neilc@samurai.com>
On Wed, 2005-12-10 at 18:54 -0400, Tom Lane wrote: > How would a typedef make it safer? I see no particular difference > between omitting the "volatile" and choosing the wrong typedef. IMHO it is notationally clearer to define a "BufferDescPtr" that contains the "volatile" qualifier than to make sure that "volatile" is used everywhere that it is needed -- obviously, neither approach is fool-proof. But perhaps that's just me... > We do however have here a New Coding Rule that's good for all parts > of the backend: if you are accessing a spinlock-protected data structure > then you should be using a volatile-qualified pointer for it. I think this is worth documenting more clearly (I realize you added a note in buf_internals.h, but perhaps a note in the spinlock headers would be appropriate as well? The comment circa line 49 of s_lock.h seems to need updating, for example.) -Neil
В списке pgsql-committers по дате отправления
От: tgl@svr1.postgresql.org (Tom Lane)
Дата: