> Well, per our discussion here in person, I'm not convinced that this
> buys us anything in the "let's replace AMQ" case. However, as I pointed
> out in my last email, this feature doesn't need to replace AMQ to be
> useful. Let's focus on the original use case of supplying a queue which
> Lond
> WAL-only tables/queues "prohobit" none of what you claim above, you just
> implement in a (loosely) MVCC way by keeping track of what events are
> processed.
Well, per our discussion here in person, I'm not convinced that this
buys us anything in the "let's replace AMQ" case. However, as I poi
On 10/23/2012 06:47 PM, Robert Haas wrote:
On Wed, Oct 17, 2012 at 4:25 PM, Josh Berkus wrote:
...
3. Double-down on #2 in a multithreaded environment.
For an application-level queue, the base functionality is:
ADD ITEM
READ NEXT (#) ITEM(S)
LOCK ITEM
DELETE ITEM
More sophisticated an usefu
On 10/23/2012 04:13 PM, Tom Lane wrote:
[ hadn't been following this thread, sorry ]
Hannu Krosing writes:
My RFC was for a proposal to skip writing the unneeded info in local
tables and put it _only_ in WAL.
This concept seems fundamentally broken. What will happen if the master
crashes imm
On Wed, Oct 17, 2012 at 4:25 PM, Josh Berkus wrote:
>> It is not meant to be a full implementation of application level queuing
>> system though but just the capture, persisting and distribution parts
>>
>> Using this as an "application level queue" needs a set of interface
>> functions to extract
[ hadn't been following this thread, sorry ]
Hannu Krosing writes:
> My RFC was for a proposal to skip writing the unneeded info in local
> tables and put it _only_ in WAL.
This concept seems fundamentally broken. What will happen if the master
crashes immediately after emitting the WAL record?
On 10/23/2012 01:31 AM, Greg Stark wrote:
On Wed, Oct 17, 2012 at 7:48 PM, Christopher Browne wrote:
Well, replication is arguably a relevant case.
For Slony, the origin/master node never cares about logged changes - that
data is only processed on replicas. Now, that's certainly a little weas
On Wed, Oct 17, 2012 at 7:48 PM, Christopher Browne wrote:
> Well, replication is arguably a relevant case.
>
> For Slony, the origin/master node never cares about logged changes - that
> data is only processed on replicas. Now, that's certainly a little weaselly
> - the log data (sl_log_*) has g
On 10/19/12 1:26 PM, Josh Berkus wrote:
What I'm saying is, we'll get nowhere promoting an application queue
which is permanently inferior to existing, popular open source software.
My advice: Forget about the application queue aspects of this. Focus
on making it work for replication and matvi
> If we describe a queue as something you put stuff in at one end and
> get it out in same or some other specific order at the other end, then
> WAL _is_ a queue when you use it for replication (if you just write to it,
> then it is "Log", if you write and read, it is "Queue")
For that matter, W
- Цитат от Hannu Krosing (ha...@krosing.net), на 19.10.2012 в
14:17 - On 10/19/2012 04:26 AM, Ants Aasma wrote:
On Thu, Oct 18, 2012 at 10:03 PM, Hannu Krosing wrote:
Hmm. Maybe we should think of implementing this as REMOTE TABLE, that
is a table which gets no real data stored locally
On 18 October 2012 18:33, Josh Berkus wrote:
>> All we're discussing is moving a successful piece of software into
>> core, which has been discussed for years at the international
>> technical meetings we've both been present at. I think an open
>> viewpoint on the feasibility of that would be re
On 10/18/2012 09:18 PM, Christopher Browne wrote:
On Thu, Oct 18, 2012 at 2:56 PM, Hannu Krosing wrote:
* works as table on INSERTS up to inserting logical WAL record describing
the
insert but no data is inserted locally.
with all things that follow from the local table having no data
- uni
On 10/19/2012 04:26 AM, Ants Aasma wrote:
On Thu, Oct 18, 2012 at 10:03 PM, Hannu Krosing wrote:
Hmm. Maybe we should think of implementing this as REMOTE TABLE, that
is a table which gets no real data stored locally but all insert got through
WAL
and are replayed as real inserts on slave side.
On Thu, Oct 18, 2012 at 10:03 PM, Hannu Krosing wrote:
> Hmm. Maybe we should think of implementing this as REMOTE TABLE, that
> is a table which gets no real data stored locally but all insert got through
> WAL
> and are replayed as real inserts on slave side.
FWIW, MySQL calls this exact concep
On Thu, Oct 18, 2012 at 2:56 PM, Hannu Krosing wrote:
> * works as table on INSERTS up to inserting logical WAL record describing
> the
> insert but no data is inserted locally.
>
> with all things that follow from the local table having no data
> - unique constraints don't make sense
> - inde
On 10/18/2012 08:36 PM, Claudio Freire wrote:
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.
Hmm. Maybe we should think of implementing this as REMOTE TABL
On 10/18/2012 07:33 PM, Josh Berkus wrote:
Simon,
It's hard to work out how to reply to this because its just so off
base. I don't agree with the restrictions you think you see at all,
saying it politely rather than giving a one word answer.
You have inside knowledge of Hannu's design.
Actua
On Thu, Oct 18, 2012 at 2:33 PM, Josh Berkus 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 bro
Simon,
> It's hard to work out how to reply to this because its just so off
> base. I don't agree with the restrictions you think you see at all,
> saying it politely rather than giving a one word answer.
You have inside knowledge of Hannu's design. I am merely going from his
description *on thi
On 17 October 2012 11:26, Hannu Krosing wrote:
> LOGGED ONLY TABLE is very technical description of realisation - I'd
> prefer it to work as mush like a table as possible, similar to how VIEW
> currently works - for all usages that make sense, you can simply
> substitute it for a TABLE
>
> QUEUE
On 17 October 2012 21:25, Josh Berkus wrote:
>
>> It is not meant to be a full implementation of application level queuing
>> system though but just the capture, persisting and distribution parts
>>
>> Using this as an "application level queue" needs a set of interface
>> functions to extract the
On Wed, Oct 17, 2012 at 4:25 PM, Josh Berkus wrote:
>
>> It is not meant to be a full implementation of application level queuing
>> system though but just the capture, persisting and distribution parts
>>
>> Using this as an "application level queue" needs a set of interface
>> functions to extra
> It is not meant to be a full implementation of application level queuing
> system though but just the capture, persisting and distribution parts
>
> Using this as an "application level queue" needs a set of interface
> functions to extract the events and also to keep track of the processed
> ev
Well, replication is arguably a relevant case.
For Slony, the origin/master node never cares about logged changes - that
data is only processed on replicas. Now, that's certainly a little
weaselly - the log data (sl_log_*) has got to get read to get to the
replica.
This suggests, nonetheless, a
On Wed, Oct 17, 2012 at 11:26 AM, Hannu Krosing wrote:
> The simplest usage would be implementing "remote log tables" that is
> tables, where you do INSERT on the master side, but it "inserts" only
> a logical WAL record and nothing else.
>
> On subscriber side your replay process reads this WAL r
On 10/17/2012 12:03 AM, Josh Berkus wrote:
Hannu,
Can you explain in more detail how this would be used on the receiving
side? I'm unable to picture it from your description.
It would be used similar to how the event tables in pgQ (from skytools)
is used - as a source of "events" to be replied
On 16 October 2012 23:03, Josh Berkus wrote:
> Can you explain in more detail how this would be used on the receiving
> side? I'm unable to picture it from your description.
This will allow implementation of pgq in core, as discussed many times
at cluster hackers meetings.
> I'm also a bit rel
Hannu,
Can you explain in more detail how this would be used on the receiving
side? I'm unable to picture it from your description.
I'm also a bit reluctant to call this a "message queue", since it lacks
the features required for it to be used as an application-level queue.
"REPLICATION MESSAGE"
On 10/16/2012 11:29 AM, Hannu Krosing wrote:
On 10/16/2012 11:18 AM, Simon Riggs wrote:
On 16 October 2012 09:56, Hannu Krosing wrote:
Hallo postgresql and replication hackers
This mail is an additional RFC which proposes a simple way to extend
the
new logical replication feature so it can
On 16 October 2012 10:29, Hannu Krosing wrote:
> I would like this to be very similar to a table, so it would be
>
> CREATE MESSAGE QUEUE(fieldname type, ...) foo;
>
> perhaps even allowing defaults and constraints. again, this
> depends on how complecxt the implementation would be.
Presumably j
On 10/16/2012 11:18 AM, Simon Riggs wrote:
On 16 October 2012 09:56, Hannu Krosing wrote:
Hallo postgresql and replication hackers
This mail is an additional RFC which proposes a simple way to extend the
new logical replication feature so it can cover most usages of
skytools/pgq/londiste
Whil
On 16 October 2012 09:56, Hannu Krosing wrote:
> Hallo postgresql and replication hackers
>
> This mail is an additional RFC which proposes a simple way to extend the
> new logical replication feature so it can cover most usages of
> skytools/pgq/londiste
>
> While the current work for BDR/LCR (bi
Hallo postgresql and replication hackers
This mail is an additional RFC which proposes a simple way to extend the
new logical replication feature so it can cover most usages of
skytools/pgq/londiste
While the current work for BDR/LCR (bi-directional replication/logical
replication)
using WAL
34 matches
Mail list logo
