$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?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Search Discussions

  • Tom Lane at Aug 16, 2011 at 4:37 am

    Robert Haas 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/.

    regards, tom lane
  • Robert Haas at Aug 16, 2011 at 1:21 pm

    On Tue, Aug 16, 2011 at 12:37 AM, Tom Lane 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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedAug 16, '11 at 2:50a
activeAug 16, '11 at 1:21p
posts3
users2
websitepostgresql.org...
irc#postgresql

2 users in discussion

Robert Haas: 2 posts Tom Lane: 1 post

People

Translate

site design / logo © 2022 Grokbase