From: | prashanth(at)jibenetworks(dot)com |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: LISTEN/NOTIFY benchmarks? |
Date: | 2003-04-29 19:54:00 |
Message-ID: | 20030429195400.GB3037@prashanth.jibenetworks.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Apr 29, 2003 at 10:10:47AM +0300, Hannu Krosing wrote:
> prashanth(at)jibenetworks(dot)com kirjutas T, 29.04.2003 kell 04:14:
> > - each client registered for thousands of LISTENs
> >
> > From a look at backend/commands/async.c, it would seem that each
> > listening backend would get a signal for *every* LISTEN it
> > registered for, resulting in thousands of signals to the same
> > listening backend, instead of only one.
>
> But as the signals are usually generated async, you have no way to know
> if a particular backend has already received a signal.
>
> Or do you mean some mechanism that remembers "signals sent" in some
> shared structure that the receiving backend can then clear when it
> actually receives the signal ?
No, I meant that a listening backend process would be sent multiple
signals from a notifying process, *in the inner loop* of
backend/commands/async.c:AtCommit_Notify().
If the listening backend had registered tens of thousands of LISTENs,
it would be sent an equivalent number of signals during a single run
of AtCommit_Notify(). I'm not sure what the cost of this is, since
I'm not sure how signal delivery works, but the tens of thousands of
system calls cannot be very cheap.
--prashanth
From | Date | Subject | |
---|---|---|---|
Next Message | Jason Tishler | 2003-04-29 20:23:37 | Re: Cygwin PostgreSQL CVS build issues |
Previous Message | Tom Lane | 2003-04-29 19:49:46 | Re: LISTEN/NOTIFY benchmarks? |