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