From: | Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com> |
---|---|
To: | torikoshia <torikoshia(at)oss(dot)nttdata(dot)com> |
Cc: | Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Change log level for notifying hot standby is waiting non-overflowed snapshot |
Date: | 2025-03-03 18:17:54 |
Message-ID: | 7d2a9f28-65ad-4470-8e87-4818d086bb5d@oss.nttdata.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2025/03/04 0:20, torikoshia wrote:
> On 2025-03-03 13:10, Fujii Masao wrote:
>
> Thanks for your comments!
>
>> On 2025/02/03 22:35, torikoshia wrote:
>>> Hi,
>>>
>>> When a hot standby is restarted in a state where subtransactions have overflowed, it may become inaccessible:
>>>
>>> $ psql: error: connection to server at "localhost" (::1), port 5433 failed: FATAL: the database system is not yet accepting connections
>>> DETAIL: Consistent recovery state has not been yet reached.
>>
>> Could you share the steps to reproduce this situation?
>
> We can reproduce this situation using the following procedure.
Thanks! I was able to reproduce the issue.
> Agreed and I feel that a message suggesting something like "check if there are any overflowing transactions on the primary side" would make it useful.
I’m wondering if this message might still be confusing for users.
Would they immediately understand what "overflowing transactions" means?
Even after reading this message, it seems also unclear what actions
they should take to resolve the issue. Plus, this message can appear
multiple times if there are multiple overflowing transactions before
starting accepting read-only connections - which could be even more confusing.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2025-03-03 18:38:38 | Re: bug when apply fast default mechanism for adding new column over domain with default value |
Previous Message | Nathan Bossart | 2025-03-03 18:11:37 | Re: Trigger more frequent autovacuums of heavy insert tables |