Listen / Notify - what to do when the queue is full
in [PgSql]
|
From: Andrew Chernow on 9 Feb 2010 19:02 Jeff Davis wrote: > On Tue, 2010-02-09 at 16:51 -0500, Tom Lane wrote: >> Limiting NOTIFY payloads to 7-bit would definitely avoid the issue. >> The question is if that's more of a pain than a benefit. > > I don't see any alternative. If one backend sends a NOTIFY payload that Wouldn't binary payloads be an alternative? NOTE: I may have missed this discussion. Sorry if it has already been covered. -- Andrew Chernow eSilo, LLC every bit counts http://www.esilo.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Jeff Davis on 9 Feb 2010 19:30 On Tue, 2010-02-09 at 19:02 -0500, Andrew Chernow wrote: > Wouldn't binary payloads be an alternative? NOTE: I may have missed this > discussion. Sorry if it has already been covered. The Notify struct has a "char *" field, which can't hold embedded NULL bytes, so it can't really be binary. But it can't be arbitrary text, because it has to be encoded in a way that works for every possible client encoding (otherwise there's a possibility of an error, and no way to handle it). Also, the query starts out as text, so we need a way to interpret the text in an encoding-independent way. So, I think ASCII is the natural choice here. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Andrew Dunstan on 9 Feb 2010 19:56 Jeff Davis wrote: > Also, the query starts out as text, so we need a way to interpret the > text in an encoding-independent way. > > So, I think ASCII is the natural choice here. > > > It's not worth hanging up this facility over this issue, ISTM. If we want something more that ASCII then a base64 or hex encoded string could possibly meet the need in the first instance. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 9 Feb 2010 20:22 Andrew Dunstan <andrew(a)dunslane.net> writes: > Jeff Davis wrote: >> So, I think ASCII is the natural choice here. > It's not worth hanging up this facility over this issue, ISTM. If we > want something more that ASCII then a base64 or hex encoded string could > possibly meet the need in the first instance. Yeah, that would serve people who want to push either binary or non-ASCII data through the pipe. It would leave all risks of encoding problems on the user's head, though. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Andrew Dunstan on 9 Feb 2010 20:32
Tom Lane wrote: > Andrew Dunstan <andrew(a)dunslane.net> writes: > >> Jeff Davis wrote: >> >>> So, I think ASCII is the natural choice here. >>> > > >> It's not worth hanging up this facility over this issue, ISTM. If we >> want something more that ASCII then a base64 or hex encoded string could >> possibly meet the need in the first instance. >> > > Yeah, that would serve people who want to push either binary or > non-ASCII data through the pipe. It would leave all risks of encoding > problems on the user's head, though. > > > True. It's a workaround, but I think it's acceptable at this stage. We need to get some experience with this facility before we can refine it. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |