Re: dynamic shared memory and locks
От | Robert Haas |
---|---|
Тема | Re: dynamic shared memory and locks |
Дата | |
Msg-id | CA+TgmobhQ6pj=dYxyufOtn7Zt__4gSFT0Gs-dCBURd8T7+-iqg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: dynamic shared memory and locks (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Mon, Jan 6, 2014 at 3:40 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> On Mon, Jan 6, 2014 at 1:55 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> OTOH, the LWLock mechanism has been stable for long enough now that >>> we can probably suppose this struct is no more subject to churn than >>> any other widely-known one, so maybe that consideration is no longer >>> significant. > >> On the whole, I'd say it's been more stable than most. But even if we >> do decide to change it, I'm not sure that really matters very much. > > Actually, the real value of a module-local struct definition is that you > can be pretty darn sure that nothing except the code in that file is > manipulating the struct contents. I would've preferred that we expose > only an abstract struct definition, but don't quite see how to do that > if we're going to embed the things in buffer headers. Agreed. I think it's good to keep struct definitions private as much as possible, and I do. But I don't think this is going to cause a big problem either; lwlocks have been around for a long time and the conventions for using them are pretty well understood, I think. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: