| From: | Nitin Jadhav <nitinjadhavpostgres(at)gmail(dot)com> |
|---|---|
| To: | Aidar Imamov <imamovaj22(at)gmail(dot)com> |
| Cc: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Disable startup progress timeout during standby WAL replay |
| Date: | 2026-10-20 15:19:51 |
| Message-ID: | CAMm1aWZpMH8AtbeyB3aj-mJHkO==FkdEzpPsYSTOMAuF+mYMNQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi Aidar,
Thanks for testing both recovery paths and confirming the behavior.
> That said, I am not sure this is the right shape. The extra hunk fixes
> a separate and pre-existing thing, and it probably wants its own thread and
> a backpatch to 15 if it worths. So bundling it into this thread may be the wrong
> move. I did it only so the bot does not lose track of things.
Nice catch on the disable_all_timeouts(false) issue. It appears to be
independent of the standby timeout cleanup discussed in this thread
and has different backpatching considerations.
> If you or anyone else thinks the two should live apart, just say so and
> I will split them: your v1 stays as is, and I will move the
> disable_all_timeouts() fix to a new thread.
+1 for splitting them. I suggest keeping Fujii-san’s standby timeout
fix in this thread and moving the recovery-conflict issue to a
separate thread and patch. That should allow the two changes to be
reviewed, tested, and considered for backpatching independently.
I have not reviewed the recovery-conflict patch in detail yet, but I
would be happy to look at it separately once it is posted in its own
thread.
Best Regards,
Nitin Jadhav
Microsoft
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeff Davis | 2026-10-20 15:22:57 | Re: [PG19] ILIKE index scan misses rows with a libc UTF-8 collation on macOS |
| Previous Message | Fujii Masao | 2026-10-20 15:08:56 | Re: 035_standby_logical_decoding might fail due to FATAL message lost inside libpq |