On Wed, Nov 2, 2016 at 4:01 AM, Joshua Kehn <josh@xxxxxxx> wrote: > That's the intention. Take the output of test_decoding, transform it > into a reasonable object form, and feed that into an events stream for > real-time consumption. Hm... > The initial question was suitability of the test_decoding plugin, given > that it is the only one I see available on RDS and requiring a switch to > a self-managed Postgres instance—to use a separate plugin—would kill > this idea. OK, and no custom binaries can be installed in this case. IMO you would have a far easier time moving to something else if you are willing to fetch custom changes or to use some of your own plugins. Vendor-locking with RDS is your problem here, and trying to use the stream from test_decoding to then modify it in the way you want is likely going to embark you in a journey you'll regret in the long term. I don't know the opinion of others on the matter... But IMO test_decoding is an example of output plugin, so there is no need to keep its output stable across major releases if any needs for another patch or feature pops in. > Are there any success/failure stories about using logical decoding as a > way of generating an events stream? There's some new question marks over > the consumer side, whether to use pg_recvlogical or something with a > peek/write to stream/pop cycle to protect the consumer from failure. pglogical has been one solution around that worked on logical decoding, and as far as I recall it uses its own protocol to replicate changes. I never had a look at it in details but that may be something to look into if you are looking for some story in this area. -- Michael -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
