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(dot)takate(at)gmail(dot)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