Re: BUG #13657: Some kind of undetected deadlock between query and "startup process" on replica.

On Fri, Oct 2, 2015 at 2:14 PM, Maxim Boguk <maxim(dot)boguk(at)gmail(dot)com> wrote:

> ​>​
> 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_delay
> 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.
>
>
> ​Problem that startup process have confict with a query, which blocked
> (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). ​
>
> PS: there are no other activity on the database during that problem except
> 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?
--
Michael