On Tue, Aug 16, 2011 at 12:37 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
