Postgres Streaming Replication interrupts queries

Postgres master and slave version:

PostgreSQL 9.5.4 on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 4.8.2-19ubuntu1) 4.8.2, 64-bit

I've successfully setup replication using SR in Postgres where slave server is ment to serve as an analytical database for such non-operational queries.

I'm constantly facing an issue with hard conflicts (as documentation mentions) where my query issued on a slave is being interrupted (> 90% of the time) with the message saying that (loosely translated)

User query could need to look through rows versions that have to be deleted

It's a conflict during recovery.

It's probably worth mentioning that production (master) database server is under constant load and is most likely editing those tuples which is why I'm losing access to the dead tuples (changing version via update?).

I've investigated pages in manual and read about:

• Handling query conflicts
• Replication servers configuration

And as a result I've applied some changes but with no success.

On master server:

vacuum_defer_cleanup_age = 500000    # raised from default 0

On slave server:

#max_standby_archive_delay = 600s    # raised from default 30s
#max_standby_streaming_delay = 600s  # raised from default 30s
#hot_standby_feedback = on           # changed from off

I've issued a service restart afther these changes. I've also changed some probably irrelevant things on the standby server (slave), so to make this post full I'm attaching it:

So my current slave server postgresql.conf looks like this:

#------------------------------------------------------------------------------
# REPLICATION
#------------------------------------------------------------------------------

# - Sending Server(s) -

# Set these on the master and on any standby that will send replication data.

max_wal_senders = 5     # max number of walsender processes
                # (change requires restart)
wal_keep_segments = 160     # in logfile segments, 16MB each; 0 disables
#wal_sender_timeout = 60s   # in milliseconds; 0 disables

#max_replication_slots = 0  # max number of replication slots
                # (change requires restart)
#track_commit_timestamp = off   # collect timestamp of transaction commit
                # (change requires restart)

# - Master Server -

# These settings are ignored on a standby server.

#synchronous_standby_names = '' # standby servers that provide sync rep
                # comma-separated list of application_name
                # from standby(s); '*' = all
#vacuum_defer_cleanup_age = 0   # number of xacts by which cleanup is delayed

# - Standby Servers -

# These settings are ignored on a master server.

hot_standby = on            # "on" allows queries during recovery
                    # (change requires restart)
#max_standby_archive_delay = 600s   # max delay before canceling queries
                    # when reading WAL from archive;
                    # -1 allows indefinite delay
#max_standby_streaming_delay = 600s # max delay before canceling queries
                    # when reading streaming WAL;
                    # -1 allows indefinite delay
#wal_receiver_status_interval = 20s # send replies at least this often
                    # 0 disables
#hot_standby_feedback = on      # send info from standby to prevent
                    # query conflicts
#wal_receiver_timeout = 120s        # time that receiver waits for
                    # communication from master
                    # in milliseconds; 0 disables
#wal_retrieve_retry_interval = 5s   # time to wait before retrying to
                    # retrieve WAL after a failed attempt

So my current master server postgresql.conf looks like this:

#------------------------------------------------------------------------------
# REPLICATION
#------------------------------------------------------------------------------

# - Sending Server(s) -

# Set these on the master and on any standby that will send replication data.

max_wal_senders = 5     # max number of walsender processes
                # (change requires restart)
wal_keep_segments = 1280    # in logfile segments, 16MB each; 0 disables
#wal_sender_timeout = 60s   # in milliseconds; 0 disables

#max_replication_slots = 0  # max number of replication slots
                # (change requires restart)
#track_commit_timestamp = off   # collect timestamp of transaction commit
                # (change requires restart)

# - Master Server -

# These settings are ignored on a standby server.

#synchronous_standby_names = '' # standby servers that provide sync rep
                # comma-separated list of application_name
                # from standby(s); '*' = all
#vacuum_defer_cleanup_age = 500000  # number of xacts by which cleanup is delayed

# - Standby Servers -

# These settings are ignored on a master server.

#hot_standby = off          # "on" allows queries during recovery
                    # (change requires restart)
#max_standby_archive_delay = 30s    # max delay before canceling queries
                    # when reading WAL from archive;
                    # -1 allows indefinite delay
#max_standby_streaming_delay = 30s  # max delay before canceling queries
                    # when reading streaming WAL;
                    # -1 allows indefinite delay
#wal_receiver_status_interval = 10s # send replies at least this often
                    # 0 disables
#hot_standby_feedback = off     # send info from standby to prevent
                    # query conflicts
#wal_receiver_timeout = 60s     # time that receiver waits for
                    # communication from master
                    # in milliseconds; 0 disables
#wal_retrieve_retry_interval = 5s   # time to wait before retrying to
                    # retrieve WAL after a failed attempt

I'd greatly appreciate any insight and am willing to provide any additional information that may be required to help me resolve this problem.