Re: Change log level for notifying hot standby is waiting non-overflowed snapshot
От | Fujii Masao |
---|---|
Тема | Re: Change log level for notifying hot standby is waiting non-overflowed snapshot |
Дата | |
Msg-id | ac9ebf32-9e3f-4939-b8c6-35693cb43af5@oss.nttdata.com обсуждение исходный текст |
Ответ на | Re: Change log level for notifying hot standby is waiting non-overflowed snapshot (torikoshia <torikoshia@oss.nttdata.com>) |
Ответы |
Re: Change log level for notifying hot standby is waiting non-overflowed snapshot
|
Список | pgsql-hackers |
On 2025/03/24 23:18, torikoshia wrote: > On 2025-03-24 00:08, Fujii Masao wrote: > >>> >>> Do you also think the errhint message is unnecessary? >>> I agree with your idea to add a description of the overflowed subtransaction in the manual, but I'm not sure all userswill be able to find it. >>> Some people may not understand what needs to be done to make the snapshot ready for hot standby. >>> I think adding an errhint may help those users. >> >> I see your concern that users might overlook the documentation and >> struggle to find a solution. However, I still believe it's better to >> include this information in the documentation rather than logging it >> as a hint. Since the scenario where the hint would be useful is >> relatively rare, logging it every time might be more confusing than helpful. > > Thanks for your opinion and it sounds reasonable. > > Attached an updated patch. Thanks for updating the patch! In high-availability.sgml, the "Administrator's Overview" section already describes the conditions for accepting hot standby connections. This section should also be updated accordingly. + brought the system to a consistent state. However, overflowed + subtransactions may also delay snapshot readiness for hot standby. In such + case, the issue can be resolved by closing the transaction containing the + overflowed subtransactions. All connections accepted by the hot standby + are strictly read-only; not even temporary tables may be written. It would be better to move this explanation about overflowed subtransactions to the "Administrator's Overview" section. - case CAC_NOTCONSISTENT: + case CAC_NOTCONSISTENT_OR_OVERFLOWED: This new name seems a bit too long. I'm OK to leave the name as it is. Or, something like CAC_NOTHOTSTANDBY seems simpler and better to me. Thought? Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION
В списке pgsql-hackers по дате отправления: