Re: BUG #16605: PostgreSQL recovery startup process waiting and blocking to application queries

At Fri, 11 Sep 2020 22:18:27 +0530, Tushar Takate <tushar11.takate@gmail.com> wrote in 
> Hi Kyotaro ,
> 
> Thanks for sharing your thoughts on this issue .
> 
> Is it expected to arrive again with the below setting or is this the bug
> with this setting ?
> 
> hot_standby_feedback= off and max_standby_streaming_delay -1 .
> 
> Because we have kept this setting intentionally on this server to avoid the
> bloat and query termination after some set time .

The table bloat means there's long transactions on the
standby. hot_standby_feedback=off means such long transactions are not
protected from query-canceling from vacuumed rows on the primary. Even
if you had such a bloat by setting it to "on", that means you would
have the same bloat when such transactions were run on the primary.

When "resolving" such bloat by setting hot_s_f to off,
max_standby_streaming_delay=-1 makes things worse by inhibiting the
system from resolving the replication-stall.

> If it's the bug ,Request you to please let me know which version contains
> the fix for it or in which version fix is going to arrive .

No. AFAICS in this report, it's the designed behavior, or a
restriction of streaming replication.

https://www.postgresql.org/docs/10/hot-standby.html

Since PG12 vacuum can run without file truncation (which leads to
access exclusive locks, see the vacuum_truncate table option) and only
the dead-lock might be avoidable by that. However even with the
option, replication doesn't advance until the causal transaction of
the replication-stall is gone.

https://www.postgresql.org/docs/13/sql-createtable.html

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center