Re: UNLISTEN, DISCARD ALL and readonly standby

Shay Rojansky <roji(at)roji(dot)org> writes:
> The documentation for DISCARD ALL[1] state that it is equivalent to a
> series of commands which includes UNLISTEN *. On the other hand, the docs
> for hot standby mode[1], state that UNLISTEN * is unsupported while DISCARD
> is (although the docs don't specify whether this includes DISCARD ALL). I
> haven't done a test, but this seems to indicate that while DISCARD ALL is
> supported in hot standby mode, UNLISTEN is not, although its functionality
> is included in the former.

Well, if there weren't

PreventCommandDuringRecovery("UNLISTEN");

in it, UNLISTEN on a standby would just be a no-op, because there'd be
nothing for it to do. DISCARD lacks that error check, but its call to
the UNLISTEN support code is still a no-op.

The reason for disallowing LISTEN/UNLISTEN on a standby is that they
wouldn't behave as a reasonable person might expect, ie seeing NOTIFY
events from the master. At some point we might allow that to happen, and
we don't want to have complaints about backwards compatibility if we do.

I guess there's an argument to be made that it'd be OK to allow UNLISTEN
but not LISTEN, but I find that argument fairly fishy. I think issuing
UNLISTEN to a standby is a likely sign of application misdesign, so I'm
not convinced we'd be doing anyone any favors by not throwing an error.

> If this is indeed the case, is there any specific reason UNLISTEN can't be
> supported? This is actually quite important in the case of Npgsql (.NET
> driver). When a connection is returned to the connection pool, its state is
> reset - usually with a DISCARD ALL. However, if prepared statements exist,
> we avoid DISCARD ALL since it destroys those (the DEALLOCATE ALL component
> of DISCARD ALL), and we want to keep prepared statements across connection
> lifecycles for performance. So instead of issuing DISCARD ALL, Npgsql sends
> the equivalent commands excluding DEALLOCATE ALL - but UNLISTEN * fails
> when in recovery.

Can't you skip that step when talking to a read-only session? I think
you're going to end up writing that code anyway, even if we accepted
this request, because it'd be a long time before you could count on
all servers having absorbed the patch.

regards, tom lane