質問

PostgreSQL has a good listen/notify system. Documentation says:

There is a queue that holds notifications that have been sent but not yet processed by all listening sessions. If this queue becomes full, transactions calling NOTIFY will fail at commit.

But I can't find out what happening with events in a specified channel that doesn't have listeners. Will notification queue overflow or will PG drop these events from queue?

役に立ちましたか?

解決

It could be more clear in the manual, but there is definitive indication that the queue is cleaned as soon as no session is actively waiting for the notification. Per documentation:

However, no cleanup can take place if a session executes LISTEN and then enters a transaction for a very long time. Once the queue is half full you will see warnings in the log file pointing you to the session that is preventing cleanup. In this case you should make sure that this session ends its current transaction so that cleanup can proceed.

That means, if nobody is listening (no active session has issued a LISTEN command on the same channel), nothing keeps Postgres from cleaning the queue instantly.

他のヒント

When a transaction that has issued NOTIFY commits, the SQL engine looks up other sessions that LISTEN at this point in time for this notification.

If there is none, the notification is thrown away. It's not queued anywhere.

It's not explained directly like that in LISTEN documentation, but as noted by @IfLoop comments, it's implied by a strict interpretation of:

...a queue that holds notifications that have been sent but not yet processed by all listening sessions.

Not yet processed by zero session means there's nothing to enqueue.

Also it makes sense because otherwise each notifier should have to worry whether there are listeners or not, which would seriously hamper the usefulness of NOTIFY.

ライセンス: CC-BY-SA帰属
所属していません StackOverflow
scroll top