Re: listen/notify argument (old topic revisited) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: listen/notify argument (old topic revisited)
Date
Msg-id 18578.1025637794@sss.pgh.pa.us
Whole thread Raw
In response to listen/notify argument (old topic revisited)  (Jeff Davis <list-pgsql-hackers@empires.org>)
List pgsql-hackers
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Why can't we do efficient indexing, or clear out the table?  I don't
> remember.

I don't recall either, but I do recall that we tried to index it and
backed out the changes.  In any case, a table on disk is just plain
not the right medium for transitory-by-design notification messages.

>> A curious statement considering that PG depends critically on SI
>> working.  This is a solved problem.

> My point is that SI was buggy for years until we found all the bugs, so
> yea, it is a solved problem, but solved with difficulty.

The SI message mechanism itself was not the source of bugs, as I recall
it (although certainly the code was incomprehensible in the extreme;
the original programmer had absolutely no grasp of readable coding style
IMHO).  The problem was failure to properly design the interactions with
relcache and catcache, which are pretty complex in their own right.
An SI-like NOTIFY mechanism wouldn't have those issues.
        regards, tom lane




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: listen/notify argument (old topic revisited)
Next
From: Tom Lane
Date:
Subject: Scope of constraint names