Re: Listen / Notify - what to do when the queue is full - Mailing list pgsql-hackers

From Greg Sabino Mullane
Subject Re: Listen / Notify - what to do when the queue is full
Date
Msg-id 204534911e82c0b6c7a2c07e743d7847@biglumber.com
Whole thread Raw
In response to Listen / Notify - what to do when the queue is full  (Joachim Wieland <joe@mcknight.de>)
Responses Re: Listen / Notify - what to do when the queue is full
Re: Listen / Notify - what to do when the queue is full
List pgsql-hackers
-----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 greg@turnstep.com
PGP Key: 0x14964AC8 200911160902
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----

iEYEAREDAAYFAksBXC0ACgkQvJuQZxSWSsh5XQCg2qPh+MovjPAdbxTmlOGu51HF
6OYAn0f+tt6lXJhVKoAAmh1QlWfRC4kl
=Izb1
-----END PGP SIGNATURE-----




pgsql-hackers by date:

Previous
From: Mark Pith
Date:
Subject: Academic research on programmers' motivation
Next
From: "Greg Sabino Mullane"
Date:
Subject: Re: Listen / Notify rewrite