Re: listen/notify argument (old topic revisited)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Jeff Davis <list-pgsql-hackers(at)empires(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: listen/notify argument (old topic revisited)
Date: 2002-07-02 19:23:14
Message-ID: 18578.1025637794@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2002-07-02 19:47:18 Re: listen/notify argument (old topic revisited)
Previous Message Jan Wieck 2002-07-02 19:14:35 Re: (A) native Windows port