You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
presence: Fix leaking of activewatchers in database (with clustering)
If you're using clustering, without tags (or with tags, but without
fallback2db), you would end up with a lot of active watchers in the
database that never got cleaned up.
Before 929ab4d:
- all stale activewatcher records in the db got purged.
After:
- if you're not clustering, all stale active watcher got purged;
- if you are, only those with the sharing_tag set.
However, the sharing tag is not necessarily set:
- it is an optional argument to handle_subscribe;
- and setting it in handle_subscribe does not write to the database
because of missing code in the fallback2db==0 bit;
- and even it it were set, then adding the argument to handle_subscribe
does not "activate" the sharing tag.
(Also interesting to know: a 408 or 481 after the
this-subscription-is-expired NOTIFY _would_ cause the individual record
to get deleted. But any other response, including 200, would leave the
record to get sorted by the periodic purge.)
This changeset reverts parts of the aforementioned commit by always
purging stale records if the sharing_tag is NULL. Thus restoring
behaviour to pre-3.1.0 and pre-2.4.8.
0 commit comments