Re: BUG #16961: Could not access status of transaction
От | Daniil Davydov |
---|---|
Тема | Re: BUG #16961: Could not access status of transaction |
Дата | |
Msg-id | CAJDiXghPYXA4n3==AA7gNjEew8M+y+VmZHybZd6bJ=m-eHPROw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #16961: Could not access status of transaction (Alexandra Wang <alexandra.wang.oss@gmail.com>) |
Ответы |
Re: BUG #16961: Could not access status of transaction
|
Список | pgsql-bugs |
Hi, On Wed, Aug 6, 2025 at 6:30 AM Alexandra Wang <alexandra.wang.oss@gmail.com> wrote: > > Thank you for sharing your interim solution! Inspired by your solution, I found > that there is an existing built-in function "pg_notification_queue_usage()"[1] > >> pg_notification_queue_usage () → double precision >> Returns the fraction (0–1) of the asynchronous notification queue's maximum >> size that is currently occupied by notifications that are waiting to be >> processed. See LISTEN and NOTIFY for more information. > > > This function calls asyncQueueAdvanceTail(). I think it's a similar workaround > to your patch, but without code change. > > What do you think? > Yep, it can be used as a workaround. But obviously the user doesn't know when this function should be called - it will become clear only when an error occurs, that is, post factum. Thus, I think that it is better to add such a functionality to the autovacuum. This simple code will ensure that there are no errors in most cases. -- Best regards, Daniil Davydov
В списке pgsql-bugs по дате отправления: