Re: Change log level for notifying hot standby is waiting non-overflowed snapshot

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

In response to

Responses

Browse pgsql-hackers by date

  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