| From: | Nitin Jadhav <nitinjadhavpostgres(at)gmail(dot)com> |
|---|---|
| To: | Kirill Reshke <reshkekirill(at)gmail(dot)com> |
| Cc: | surya poondla <suryapoondla4(at)gmail(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Reporting WAL replay progress during pre-consistency standby reovery |
| Date: | 2026-11-09 14:27:17 |
| Message-ID: | CAMm1aWb-dmnuAqoVo+rttVOHceH3gijNHf_kFdZfTnRvZ65Tvw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi Kiril,
> During recovery, if you try to connect to the database via psql, you
> will get an error message: "the database system is not yet accepting
> connection"/"Consistent recovery state has not been yet reached." etc.
> What if we report the current replay LSN here?
Thanks for the suggestion. Since crash recovery already reports replay
progress through the server log, I think using the same mechanism for
standby recovery before consistency is preferable than introducing a
different reporting method.
Also, this connection error is returned before authentication, so
adding the replay LSN would expose recovery information to
unauthenticated clients and may need separate consideration.
For this patch, I would prefer to keep the existing server-log
approach, while the connection-error approach can be explored
separately.
Best Regards,
Nitin Jadhav
Microsoft
| From | Date | Subject | |
|---|---|---|---|
| Previous Message | Alain LESAGE | 2026-11-09 14:24:02 | Re: Improve hash aggregate spilling by writing only the needed columns |