On Fri, Oct 2, 2015 at 2:14 PM, Maxim Boguk <maxim.boguk@gmail.com> wrote:
> =E2=80=8B>=E2=80=8B
> This backtrace is not indicating that this process is waiting on a
> relation lock, it is resolving a recovery conflict while removing tuples,
> killing the virtual transaction depending on if max_standby_streaming_del=
ay
> or max_standby_archive_delay are set if the conflict gets longer. Did you
> change the default of those parameters, which is 30s, to -1? This would
> mean that the standby waits indefinitely.
>
>
> =E2=80=8BProblem that startup process have confict with a query, which bl=
ocked
> (waiting for) on the startup process itself (query could not process
> because it waiting for lock which held by startup process, and startup
> process waiting for finishing this query). So it's an undetected deadlock
> condtion here (as I understand situation). =E2=80=8B
>
> PS: there are no other activity on the database during that problem excep=
t
> blocked query.
>
Don't you have other queries running in parallel of the one you are
defining as "stuck" on the standby that prevent replay to move on? Like a
long-running transaction working on the relation involved? Are you sure
that you did not set up max_standby_streaming_delay to -1?
--=20
Michael
