Re: Built-in plugin for logical decoding output

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Alvaro Hernandez <aht(at)ongres(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Euler Taveira <euler(at)timbira(dot)com(dot)br>, Gregory Brail <gregbrail(at)google(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Built-in plugin for logical decoding output
Date: 2017-09-26 09:03:36
Message-ID: CABUevEzU8WxX9Gtt90wUtQ9=OWA92VveVKmD7V70wHSPPBx4KA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Sep 26, 2017 at 7:42 AM, Alvaro Hernandez <aht(at)ongres(dot)com> wrote:

>
>
> On 25/09/17 22:13, Magnus Hagander wrote:
>
> On Mon, Sep 25, 2017 at 8:20 PM, Alvaro Hernandez <aht(at)ongres(dot)com> wrote:
>
>>
>>
>> On 25/09/17 20:18, Andres Freund wrote:
>>
>>> On 2017-09-24 13:36:56 +0300, Alvaro Hernandez wrote:
>>>
>>>> However, if DMS uses it for what I'd call production use, I assume
>>>> it is
>>>> actually production quality. I bet they do enough testing, and don't
>>>> ship
>>>> software to potentially millions of customers if it doesn't work well.
>>>> So...
>>>> first, I'd consider this a a sign of robustness.
>>>>
>>> You've been in software for how long? ... ;) There's quite mixed
>>> experiences with DMS.
>>>
>>
>> Actually long enough to understand that if someone "big" calls it
>> production quality, we should not be pickier and assume it is --whether it
>> is or not. People will accept it as such, and that's good enough.
>>
>
> Historically the fact that we have been pickier than many of the "someone
> big":s is exactly how we ended up with the codebase and relative stability
> we have today.
>
> Just because someone is big doesn't mean they know what's right. In fact,
> more often than not the opposite turns out to be true.
>
>
>
> Note that I'm not here supporting test_decoding. I'm just saying is
> all what is available in-core for 9.4-9.6, and it seems someone with
> potentially a lot of users tested it and is using it in its own solution.
> Ask me if I would like an in-core, well tested, performant, with an easy to
> parse format, and efficient, for 9.4-9.6? My answer would be an immediate
> 'yes'. But since this is not going to happen, test_decoding is good that is
> good enough, lucky us, because otherwise there would not be a good solution
> on this front.
>

I am not saying we shouldn't have that. I am saying that the argument "if
someone big calls it production quality, we should not be pickier and
assume it is" is incorrect.

And yes, I have used test_decoding in production multiple times. And yes,
there are good reasons why it's called *test* decoding, and should only be
used in production in fairly simple cases :)

--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/>
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2017-09-26 09:06:51 Re: Transactions involving multiple postgres foreign servers
Previous Message Amit Langote 2017-09-26 08:59:30 Re: Shaky coding for vacuuming partitioned relations