| From: | <julien(at)jdemoor(dot)com> |
|---|---|
| To: | "'Catalin Iacob'" <iacobcatalin(at)gmail(dot)com> |
| Cc: | "'Pg Hackers'" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | RE: NOTIFY and pg_notify performance when deduplicating notifications |
| Date: | 2018-10-09 12:17:08 |
| Message-ID: | 028301d45fca$020595e0$0610c1a0$@jdemoor.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> Indeed, I have the same and am very interested in this.
>
> > I hope this patch can be reviewed and included in PostgreSQL.
>
> I added this to the next Commitfest and added myself as a reviewer.
> Will try to a review beginning of next week.
> https://commitfest.postgresql.org/20/1820/
Thank you for reviewing.
I just caught an error in my patch, it's fixed in the attachment. The 'never' and 'maybe' collapse modes were mixed up in one location.
I can't find a reasonable way to build a regression test that checks whether notifications are effectively deduplicated. The output of the LISTEN command lists the PID of the notifying backend for each notification, e.g. : 'Asynchronous notification "foobar" received from server process with PID 24917'. I can't just add this to async.out. I did test manually for all eight combinations : four collapse mode values (missing, empty string, 'maybe' and 'never'), both with NOTIFY and pg_notify().
| Attachment | Content-Type | Size |
|---|---|---|
| postgres-notify-all-v7.patch | application/octet-stream | 14.2 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2018-10-09 12:54:12 | Re: Refactor textToQualifiedNameList() |
| Previous Message | Michael Paquier | 2018-10-09 11:25:46 | Re: partition tree inspection functions |