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 pointed
On 10/23/2012 04:13 PM, Tom Lane wrote:
[ hadn't been following this thread, sorry ]
Hannu Krosing ha...@2ndquadrant.com 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
On 10/23/2012 06:47 PM, Robert Haas wrote:
On Wed, Oct 17, 2012 at 4:25 PM, Josh Berkus j...@agliodbs.com 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
On 10/23/2012 01:31 AM, Greg Stark wrote:
On Wed, Oct 17, 2012 at 7:48 PM, Christopher Browne cbbro...@gmail.com 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
[ hadn't been following this thread, sorry ]
Hannu Krosing ha...@2ndquadrant.com 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
On Wed, Oct 17, 2012 at 4:25 PM, Josh Berkus j...@agliodbs.com 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
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
On Wed, Oct 17, 2012 at 7:48 PM, Christopher Browne cbbro...@gmail.com 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
On 10/19/2012 04:26 AM, Ants Aasma wrote:
On Thu, Oct 18, 2012 at 10:03 PM, Hannu Krosing ha...@2ndquadrant.com 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
On 10/18/2012 09:18 PM, Christopher Browne wrote:
On Thu, Oct 18, 2012 at 2:56 PM, Hannu Krosing ha...@2ndquadrant.com 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
On 18 October 2012 18:33, Josh Berkus j...@agliodbs.com 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
- Цитат от 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
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, WAL is a
On 17 October 2012 21:25, Josh Berkus j...@agliodbs.com 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
On 17 October 2012 11:26, Hannu Krosing ha...@2ndquadrant.com 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
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 this
On Thu, Oct 18, 2012 at 2:33 PM, Josh Berkus j...@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
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.
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
On Thu, Oct 18, 2012 at 2:56 PM, Hannu Krosing ha...@2ndquadrant.com 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
On Thu, Oct 18, 2012 at 10:03 PM, Hannu Krosing ha...@2ndquadrant.com 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
On 16 October 2012 23:03, Josh Berkus j...@agliodbs.com 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
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 Wed, Oct 17, 2012 at 11:26 AM, Hannu Krosing ha...@2ndquadrant.com 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
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
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
events.
On Wed, Oct 17, 2012 at 4:25 PM, Josh Berkus j...@agliodbs.com 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
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
On 16 October 2012 09:56, Hannu Krosing ha...@2ndquadrant.com 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
On 16 October 2012 10:29, Hannu Krosing ha...@2ndquadrant.com 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
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 ha...@2ndquadrant.com wrote:
Hallo postgresql and replication hackers
This mail is an additional RFC which proposes a simple way to extend
the
new logical
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,
32 matches
Mail list logo
