Re: Validity of using the test_decoding plugin for production?

On Wed, Nov 2, 2016 at 4:01 AM, Joshua Kehn <josh(at)kehn(dot)us> 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