Re: [HACKERS] PG-MQ?

On 6/20/07, Chris Browne <[EMAIL PROTECTED]> wrote: [EMAIL PROTECTED] ("Marko Kreen") writes: > To Chris: you should like PgQ, its just stored procs in database, > plus it's basically just generalized Slony-I, with some optimizations, > so should be familiar territory ;) Looks interesting... T

Re: [HACKERS] PG-MQ?

[EMAIL PROTECTED] ("Marko Kreen") writes: > To Chris: you should like PgQ, its just stored procs in database, > plus it's basically just generalized Slony-I, with some optimizations, > so should be familiar territory ;) Looks interesting... Random ideas - insert_event in C (way to ge

Re: [HACKERS] PG-MQ?

On 6/20/07, Rob Butler <[EMAIL PROTECTED]> wrote: Do you guys need something PG specific or built into PG? Yes, we need it usable from inside the DB, thus the PgQ. That means the events are also transactional with other things happening in the DB. ActiveMQ is very nice, speaks multiple langu

Re: [HACKERS] PG-MQ?

On Wed, June 20, 2007 19:42, Rob Butler wrote: > Do you guys need something PG specific or built into PG? > > ActiveMQ is very nice, speaks multiple languages, protocols and supports a > ton of features. Could you simply use that? > > http://activemq.apache.org/ Looks very nice indeed! Jeroen

Re: [HACKERS] PG-MQ?

Do you guys need something PG specific or built into PG? ActiveMQ is very nice, speaks multiple languages, protocols and supports a ton of features. Could you simply use that? http://activemq.apache.org/ Rob ___

Re: [HACKERS] PG-MQ?

Jeroen T. Vermeulen wrote: On Wed, June 20, 2007 18:18, Heikki Linnakangas wrote: Marko Kreen wrote: As I understand, JMS does not have a concept of transactions, probably also other solutions mentioned before, so to use PgQ as backend for them should be much simpler... JMS certainly does have

Re: [HACKERS] PG-MQ?

On Wed, June 20, 2007 18:18, Heikki Linnakangas wrote: > Marko Kreen wrote: >> As I understand, JMS does not have a concept >> of transactions, probably also other solutions mentioned before, >> so to use PgQ as backend for them should be much simpler... > > JMS certainly does have the concept of t

Re: [HACKERS] PG-MQ?

On 6/20/07, Heikki Linnakangas <[EMAIL PROTECTED]> wrote: Marko Kreen wrote: > As I understand, JMS does not have a concept > of transactions, probably also other solutions mentioned before, > so to use PgQ as backend for them should be much simpler... JMS certainly does have the concept of tran

Re: [HACKERS] PG-MQ?

Marko Kreen wrote: As I understand, JMS does not have a concept of transactions, probably also other solutions mentioned before, so to use PgQ as backend for them should be much simpler... JMS certainly does have the concept of transactions. Both distributed ones through XA and two-phase commi

Re: [HACKERS] PG-MQ?

On 6/20/07, Jeroen T. Vermeulen <[EMAIL PROTECTED]> wrote: On Wed, June 20, 2007 04:45, Chris Browne wrote: > - Sometimes you have the semantics where: > - messages need to be delivered at least once > - messages need to be delivered no more than once > - messages need to be delivered exact

Re: [HACKERS] PG-MQ?

Hi Chris, Chris Browne wrote: I'm seeing some applications where it appears that there would be value in introducing asynchronous messaging, ala "message queueing." ISTM that 'message queue' is a way too general term. There are hundreds of differen

Re: [HACKERS] PG-MQ?

On Wed, June 20, 2007 04:45, Chris Browne wrote: > I'm seeing some applications where it appears that there would be > value in introducing asynchronous messaging, ala "message queueing." > > > The "granddaddy" of message queuing systems is IBM's MQ-Seri

Re: [HACKERS] PG-MQ?

[EMAIL PROTECTED] (Steve Atkins) writes: >> Is there any existing work out there on this? Or should I maybe be >> looking at prototyping something? > > The skype tools have some sort of decent-looking publish/subscribe > thing, PgQ, then they layer their replication on top of. It's multi > consume

Re: [HACKERS] PG-MQ?

On Jun 19, 2007, at 2:45 PM, Chris Browne wrote: I'm seeing some applications where it appears that there would be value in introducing asynchronous messaging, ala "message queueing." Me too. My bias would be to have something that can basically

[HACKERS] PG-MQ?

I'm seeing some applications where it appears that there would be value in introducing asynchronous messaging, ala "message queueing." The "granddaddy" of message queuing systems is IBM's MQ-Series, and I don't see particular value in replicating its fu