Re: src/backend/storage/ipc/README
От | Robert Haas |
---|---|
Тема | Re: src/backend/storage/ipc/README |
Дата | |
Msg-id | CA+TgmoYQ5hTwFTuOz28yDRdLCrHuBG36TSjGNHbEhdMDxKw=Ag@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: src/backend/storage/ipc/README (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Tue, Aug 16, 2011 at 12:37 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> $SUBJECT is wildly out-of-date. Is there any point in keeping this, >> given the large (and actually correct) comment block near the top of >> sinvaladt.c? > > Huh, I never noticed that file before. Yeah, it seems useless as it > stands. I wonder however if we could repurpose it as a slightly > higher-level summary? If you just look at sinval(adt).c, you'll find > out all about how inval messages get transmitted, but nothing about why > we need them in the first place. There's some material about that over > in src/backend/utils/cache/inval.c, which is not the easiest place to > find if you're looking at storage/ipc/. That's for sure. IMHO, the fact that this functionality is broken up between three source files in two completely separate parts of the source tree is a mistake to begin with. It appears to me to be an attempt to create proper layers of abstraction, but in reality I think it's just an obstacle to understanding and improving the code. I would suggest merging inval.c into sinval.c so that it's all in src/backend/storage/ipc. That having been said, some more documentation of what sinval is for and what its restrictions are would be great. I wonder if it shouldn't go into a file called README.sinval or somesuch, though. The functionality in that directory is fairly diverse and you could conceivably end up with README.procarray, README.shmem, etc. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: