From: | Hannu Krosing <hannu(at)tm(dot)ee> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, 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-03 16:09:34 |
Message-ID: | 1025712574.23475.80.camel@taru.tm.ee |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, 2002-07-03 at 16:30, Tom Lane wrote:
> Hannu Krosing <hannu(at)tm(dot)ee> writes:
> > There could a little more smartness here to avoid unneccessary copying
> > (not just storing) of not-listened-to data.
>
> Yeah, I was wondering about that too.
>
> > I guess that depending on the circumstances this can be either faster or
> > slower than copying them all in one memmove.
>
> The more interesting question is whether it's better to hold the read
> lock on the shared buffer for the minimum possible amount of time;
OTOH, we may decide that getting a notify ASAP is not a priority and
just go on doing what we did before if we can't get the lock and try
again the next time around.
This may have some pathological behaviours (starving some backends who
always come late ;), but we are already attracting a thundering herd by
sending a signal to all _possibly_ interested backends at the same time
time.
Keeping a list of who listens to what can solve this problem (but only
in case of sparse listening habits).
-----------------
Hannu
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2002-07-03 16:09:40 | Re: (A) native Windows port |
Previous Message | Tom Lane | 2002-07-03 15:51:06 | Re: listen/notify argument (old topic revisited) |