I want to tell you about the problem solution. I had to move to postgres 13.
As can be seen from the async.c code, since the 13th version, the
implementation of the LISTEN/NOTIFY mechanism has undergone major changes. The
transfer of tables and database data from version 10 to versio
I decided to rebuild pg 10 first.
I commented out the lines of code with duplicate checking
(/src/backend/commands/async.c)
// if (AsyncExistsPendingNotify(channel, payload))
// return;
and launched this version of pg into production.
This was the only way I could figure out if there
=?UTF-8?B?0JDRgNGB0LXQvSDQkNGA0YPRgtGO0L3Rj9C9?= writes:
> i looked at the file "\src\backend\commands\async.c"
> there is a check for duplicate messages
Yup.
> Is this slowdown related to this check?
[ shrug... ] You've provided no evidence either for or against that
possibility.
It seems a
i looked at the file "\src\backend\commands\async.c"
there is a check for duplicate messages
/ PG 10
if (AsyncExistsPendingNotify(channel, payload))
return;
***/
/ PG 13
if (AsyncExistsPendingNotify(n))
{
…...
}
***/
Is this slowdown related to this check?
Is it
=?UTF-8?B?0JDRgNGB0LXQvSDQkNGA0YPRgtGO0L3Rj9C9?= writes:
> Hello! I'm having trouble with LISTEN/NOTIFY speed. Now I have about
> 100-200 (few?) clients who are actively messaging. But recently I started to
> notice a drop in speed. Changing the log_min_duration_statement parameter did
> no
Hello! I'm having trouble with LISTEN/NOTIFY speed. Now I have about
100-200 (few?) clients who are actively messaging. But recently I started to
notice a drop in speed. Changing the log_min_duration_statement parameter did
not show slow queries in the log.
As it turned out, the pg_noti
