Re: [RFC] CREATE QUEUE (log-only table) for londiste/pgQ ccompatibility
От | Claudio Freire |
---|---|
Тема | Re: [RFC] CREATE QUEUE (log-only table) for londiste/pgQ ccompatibility |
Дата | |
Msg-id | CAGTBQpZVMmvNk5GqqutuQeWaBikEgHqJZT3ntA-d1QDPqJjobw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [RFC] CREATE QUEUE (log-only table) for londiste/pgQ ccompatibility (Josh Berkus <josh@agliodbs.com>) |
Ответы |
Re: [RFC] CREATE QUEUE (log-only table) for londiste/pgQ
ccompatibility
|
Список | pgsql-hackers |
On Thu, Oct 18, 2012 at 2:33 PM, Josh Berkus <josh@agliodbs.com> wrote: >> I should also add that this is an switchable sync/asynchronous >> transactional queue, whereas LISTEN/NOTIFY is a synchronous >> transactional queue. > > Thanks for explaining. New here, I missed half the conversation, but since it's been brought up and (to me wrongfully) dismissed, I'd like to propose: NOTIFY [ALL|ONE] [REMOTE|LOCAL|CLUSTER|DOWNSTREAM] ASYNCHRONOUSLY LISTEN [REMOTE|LOCAL|CLUSTER|UPSTREAM] too for good measure. That ought to work out fine as SQL constructs go, implementation aside. That's not enough for matviews, but it is IMO a good starting point. All you need after that, are triggers for notifying automatically upon insert, and some mechanism to attach triggers to a channel for the receiving side. Since channels are limited to short strings, maybe a different kind of object (but with similar manipulation syntax) ought to be created. The CREATE QUEUE command, in fact, could be creating such a channel. The channel itself won't be WAL-only, just the messages going through it. This (I think) would solve locking issues.
В списке pgsql-hackers по дате отправления: