Listen / Notify - what to do when the queue is full
in [PgSql]
|
From: "Greg Sabino Mullane" on 10 Jan 2010 23:05 -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 >>> - do we need to limit the payload to pure ASCII ? I think yes, we need >>> to. I also think we need to reject other payloads with elog(ERROR...). >...[snip other followups] On the one hand, I don't see the problem with ASCII here - the payload is meant as a quick shorthand convenience, not a literal payload of important information. On the other, it should at least match the current rules for the listen and notify names themselves, which means allowing more than ASCII. - -- Greg Sabino Mullane greg(a)turnstep.com PGP Key: 0x14964AC8 201001102303 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAktKo40ACgkQvJuQZxSWSshg9ACg2uiDYuhBnRQqFS6Ej3O9VLcC 2TgAn035OrYcdERn4I1VI4NRQFBIcXZ/ =yJmK -----END PGP SIGNATURE----- -- 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: Peter Eisentraut on 11 Jan 2010 01:58 On mån, 2010-01-11 at 04:05 +0000, Greg Sabino Mullane wrote: > On the one hand, I don't see the problem with ASCII here - the > payload is meant as a quick shorthand convenience, not a literal payload > of important information. Is it not? The notify name itself is already a quick shorthand convenience. Who knows what the payload is actually meant for. Have use cases been presented and analyzed? -- 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: Arnaud Betremieux on 11 Jan 2010 05:05 A use case : use NOTIFY in a rule to send the primary key of a row that has been updated (for instance to manage a cache). This requires a patch on top of this one, and it really is a separate concern, but I thought I'd give the use case anyway, since I believe it is relevant to the issues here. I can see four kinds of NOTIFY statements : 1) The existing case : NOTIFY channel 2) With Joachim's patch : NOTIFY channel 'payload' 3) My use case : NOTIFY channel 'pay'||'load' (actually NOTIFY channel '<table_name>#'||OLD.id) 4) Taken one step further : NOTIFY channel (SELECT payload FROM payloads WHERE ...) I'm working on a proof of concept patch to use Joachim's new notify function to introduce case 3. I think this means going through the planner and executor, so I might as well do case 4 as well. A use case I can see for case 4 is sending information in a rule or trigger about an updated object, when that information is stored in a separate table (versioning or audit information for example). Cases 1 and 2 could remain utility commands, while cases 3 and 4 could go through the planner and the executor, the notify plan node calling Joachim's new notify function on execution. Best regards, Arnaud Betremieux On 11/01/2010 07:58, Peter Eisentraut wrote: > On mån, 2010-01-11 at 04:05 +0000, Greg Sabino Mullane wrote: > >> On the one hand, I don't see the problem with ASCII here - the >> payload is meant as a quick shorthand convenience, not a literal payload >> of important information. >> > Is it not? The notify name itself is already a quick shorthand > convenience. Who knows what the payload is actually meant for. Have > use cases been presented and analyzed? > > > > -- 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 11 Jan 2010 08:25 Arnaud Betremieux <arnaud.betremieux(a)keyconsulting.fr> writes: > 3) My use case : NOTIFY channel 'pay'||'load' (actually NOTIFY > channel '<table_name>#'||OLD.id) > 4) Taken one step further : NOTIFY channel (SELECT payload FROM payloads > WHERE ...) > I'm working on a proof of concept patch to use Joachim's new notify > function to introduce case 3. I think this means going through the > planner and executor, so I might as well do case 4 as well. It would be a lot less work to introduce a function like send_notify() that could be invoked within a regular SELECT. Pushing a utility statement through the planner/executor code path will do enough violence to the system design that such a patch would probably be rejected out of hand. 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 Chernow on 11 Jan 2010 08:34
Arnaud Betremieux wrote: > A use case : use NOTIFY in a rule to send the primary key of a row that > has been updated (for instance to manage a cache). > > This requires a patch on top of this one, and it really is a separate > concern, but I thought I'd give the use case anyway, since I believe it > is relevant to the issues here. > > I can see four kinds of NOTIFY statements : > > 1) The existing case : NOTIFY channel > 2) With Joachim's patch : NOTIFY channel 'payload' > 3) My use case : NOTIFY channel 'pay'||'load' (actually NOTIFY > channel '<table_name>#'||OLD.id) > 4) Taken one step further : NOTIFY channel (SELECT payload FROM payloads > WHERE ...) > I know I'd be looking to send utf8 and byteas. Can notify as it stands today take an expression for the payload (#4)? The other issue is that libpq expects a string, so if non-c-string safe data is to be sent a protocol change is needed or the server must hex encode all payloads before transit and libpq must decode it; also requiring an 'payload_len' member be added to PGnotify. The latter is better IMHO as protocol changes are nasty. Although, only needed to support bytea. If all we want is utf8, then there is no issue with libpq. -- 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 |