From: | Claudio Freire <klaussfreire(at)gmail(dot)com> |
---|---|
To: | Josh Berkus <josh(at)agliodbs(dot)com> |
Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, Hannu Krosing <hannu(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [RFC] CREATE QUEUE (log-only table) for londiste/pgQ ccompatibility |
Date: | 2012-10-18 18:36:09 |
Message-ID: | CAGTBQpZVMmvNk5GqqutuQeWaBikEgHqJZT3ntA-d1QDPqJjobw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Oct 18, 2012 at 2:33 PM, Josh Berkus <josh(at)agliodbs(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2012-10-18 18:48:31 | Re: Bugs in CREATE/DROP INDEX CONCURRENTLY |
Previous Message | Alvaro Herrera | 2012-10-18 18:19:56 | Re: [v9.3] Row-Level Security |