Re: Spec discussion: Generalized Data Queue / Modification Trigger

Greg,

>> (1) The ability to send asynchronous (or synchronous?) notifications, on
>> a per-row basis, whenever data is modified *only after commit*.  This
>> has been generally described as "on-commit triggers", but could actually
>> take a variety of forms.
>
> I'm not sure I like the idea of this. Could be potentially dangerous, as
> listen/notify is not treated as a "reliable" process. What's wrong with
> the current method, namely having a row trigger update an internal
> table, and then a statement level trigger firing off a notify?

Well, the main problem with that is that it doubles the number of writes
you have to do ... or more.  So it's a major efficiency issue.

This isn't as much of a concern for a system like Slony or Londiste
where the replication queue is a table in the database.  But if you
were, say, replicating through ApacheMQ?  Or replicating cached data to
Redis?  Then the whole queue-table, NOTIFY, poll structure is needless
overhead.

>> (3) A method of marking DDL changes in the data modification stream.
>
> Hmm..can you expand on what you have in mind here? Something more than
> just treating the DDL as another item in the (txn ordered) queue?

Yeah, that would be one way to handle it.  Alternately, you could have
the ability to mark rows with a DDL "version".

--Josh Berkus