On Mon, Feb 24, 2003 at 09:21:47AM -0500, Tom Lane wrote:
>
> I'd be happier with it if there were a switch that enabled this behavior
> (and it were *not* on by default). That would eliminate one of the
> things that was bothering me, which was the prospect of every psql
> everywhere consuming cycles to check for notifications. If you did that
> it would likely also be acceptable to print notifications in the midst
> of type-in.
So your only objection is which should be the default setting for the
switch? In that case I can just go ahead and implement this as planned,
with the controlling variable I mentioned earlier set to the current
behaviour by default.
As for cycle consumption, I think there are mitigating factors:
1. Since the backend pushes notifications out the frontend anyway, no
extra backend or network cycles are used. The cost is paid entirely on
the side of the client, so the problem case is where a single machine
runs an enourmous number of psql clients. How many psql clients may
access a single server from various remote machines does not come into
the equation. (I suppose that would be the main scalability worry)
2. In the case where readline is not used, I don't think there is any
need to busy-wait. It shouldn't be very hard to select() on the backend
socket and the command input fd at the same time. Dunno about the
readline case though; if that doesn't support some form of timeout or
nonblocking operation, notifications can only be checked when input
occurs anyway.
3. It would be a little extra work, but perhaps not undoable, to keep
track of whether the client is actually listening on any triggers. If
not, there's no need to poll anything. Similarly, there's no need to
poll while inside a transaction because no notifications will be
delivered in that state.
Jeroen
