Jeff Davis <[EMAIL PROTECTED]> writes:
> Regarding UNLISTEN: 'UNLISTEN <name>' does not remove
> LISTEN entries for '<name>' in 'pg_listener' class,
> nor does it prevent NOTIFYication.
It appears that this breakage is due to failure to maintain the index
on pg_listener that was added in 7.0. UNLISTEN <name> is the only
operation that tries to use the index, and it's failing because there
are paths in async.c that don't bother to create an index entry for
inserted tuples. Another way to show there is a problem is:
regression=# vacuum pg_listener;
VACUUM
regression=# listen test;
LISTEN
regression=# vacuum pg_listener;
NOTICE: Index pg_listener_relname_pid_index: NUMBER OF INDEX' TUPLES (0) IS NOT THE
SAME AS HEAP' (1).
Recreate the index.
VACUUM
As far as I can tell, the index on pg_listener doesn't even begin to
approach usefulness; speeding up UNLISTEN (which most apps never do at
all, or at most once) is a poor return on the cost of updating the index
(twice!) for every NOTIFY. Therefore, rather than adding the missing
code, what I'd really like to do is rip out the index and revert async.c
to its indexless state.
However, I don't see any way to get rid of that index completely without
an initdb, and it's too late for initdb in the 7.0 cycle. If the index
exists and async.c simply doesn't bother to update it, then we'll get
notices like the above from VACUUM. Can anyone see a way around that?
regards, tom lane
