Re: src/backend/storage/ipc/README

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: src/backend/storage/ipc/README
Date: 2011-08-16 13:21:39
Message-ID: CA+TgmoYQ5hTwFTuOz28yDRdLCrHuBG36TSjGNHbEhdMDxKw=Ag@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Aug 16, 2011 at 12:37 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2011-08-16 13:25:15 Re: Some problems about cascading replication
Previous Message Alexander Korotkov 2011-08-16 13:19:14 Re: WIP: Fast GiST index build