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/>
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 |