clarification regarding max_standby_streaming_delay

Hi,

We have a setup Streaming Replication with max_standby_streaming_delay=120s
if statements are getting canceled with on the standby server with
messages like below:

FATAL: terminating connection due to conflict with recovery
DETAIL: User query might have needed to see row versions that must be removed.
HINT: In a moment you should be able to reconnect to the database and
repeat your command.

can we draw conclusion that
Queries that are conflicting with application of the wal entries were
very slow and
ran over 120s

according to docs:
http://developer.postgresql.org/pgdocs/postgres/runtime-config-wal.html#GUC-MAX-STANDBY-ARCHIVE-DELAY
max_standby_streaming_delay (integer)
When Hot Standby is active, this parameter determines how long the
standby server should wait before canceling standby queries that
conflict with about-to-be-applied WAL entries, as described in Section
25.5.2. max_standby_streaming_delay applies when WAL data is being
received via streaming replication. The default is 30 seconds. Units
are milliseconds if not specified. A value of -1 allows the standby to
wait forever for conflicting queries to complete. This parameter can
only be set in the postgresql.conf file or on the server command line.

Note that max_standby_streaming_delay is not the same as the
maximum length of time a query can run before cancellation; rather it
is the maximum total time allowed to apply WAL data once it has been
received from the primary server. Thus, if one query has resulted in
significant delay, subsequent conflicting queries will have much less
grace time until the standby server has caught up again.