-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160
> We still need to decide what to do with queue full situations in > the proposed listen/notify implementation. I have a new version > of the patch to allow for a variable payload size. However, the > whole notification must fit into one page so the payload needs > to be less than 8K. That sounds fine to me, FWIW. > I have also added the XID, so that we can write to the queue before > committing to clog which allows for rollback if we encounter write > errors (disk full for example). Especially the implications of this > change make the patch a lot more complicated. Can you elaborate on the use case for this? > so it won't update its pointer for some time. With the current space we can > acommodate at least 2147483647 notifications or more, depending on the > payload length. That's a whole lot of notifications. I doubt any program out there is using anywhere near that number at the moment. In my applications, having a few hundred notifications active at one time is "a lot" in my book. :) > These are the solutions that I currently see: > > 1) drop new notifications if the queue is full (silently or with rollback) I like this one best, but not with silence of course. While it's not the most polite thing to do, this is for a super extreme edge case. I'd rather just throw an exception if the queue is full rather than start messing with the readers. It's a possible denial of service attack too, but so is the current implementation in a way - at least I don't think apps would perform very optimally with 2147483647 entries in the pg_listener table :) If you need some real-world use cases involving payloads, let me know, I've been waiting for this feature for some time and have it all mapped out. - -- Greg Sabino Mullane g...@turnstep.com PGP Key: 0x14964AC8 200911160902 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAksBXC0ACgkQvJuQZxSWSsh5XQCg2qPh+MovjPAdbxTmlOGu51HF 6OYAn0f+tt6lXJhVKoAAmh1QlWfRC4kl =Izb1 -----END PGP SIGNATURE----- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
