Re: Can LISTEN/NOTIFY deal with more than 100 every second?

From: Gavin Mu <gavin(dot)mu(at)gmail(dot)com>
To: Yeb Havinga <yhavinga(at)gmail(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Can LISTEN/NOTIFY deal with more than 100 every second?
Date: 2010-02-02 12:05:47
Message-ID: 708189661002020405m23eac89dh2927bda5a7655ede@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

with your reminder I had a look at the code of the LISTEN/NOTIFY
implementation, NOTIFY <name> will send SIGUSR2 signal to the backend
if it's not for itself. I guess frequent singal handling can't be
handled on time.

2010/2/1 Yeb Havinga <yhavinga(at)gmail(dot)com>:
> Gavin Mu wrote:
>>
>> CREATE OR REPLACE RULE send_notify AS ON INSERT TO log DO ALSO NOTIFY
>> logevent;
>>
>
> ..
>>
>> when I use 3 similar programs to feed data, which means about 75
>> events every second, I found that Postgres didn't send NOTIFY
>> opportunely, since the client do SELECT query every several hundreds
>> seconds, which is too long to be acceptable.
>>
>
> Hello Gavin,
>
> The following might help from the notify docs:
>
> "NOTIFY behaves like Unix signals in one important respect: if the same
> notification name is signaled multiple times in quick succession, recipients
> might get only one notification event for several executions of NOTIFY."
>
> So if your notify for instance could also add a unique number to the
> notification name, then it will probably work as expected.
>
> Regards,
> Yeb Havinga
>
>
>

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Vincenzo Romano 2010-02-02 12:26:34 Partitioning: indexes, tables and FKs
Previous Message Clemens Schwaighofer 2010-02-02 11:17:20 Problem with partition tables and schemas