Re: [HACKERS] Built-in plugin for logical decoding output

Поиск
Список
Период
Сортировка
От Magnus Hagander
Тема Re: [HACKERS] Built-in plugin for logical decoding output
Дата
Msg-id CABUevEzU8WxX9Gtt90wUtQ9=OWA92VveVKmD7V70wHSPPBx4KA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Built-in plugin for logical decoding output  (Alvaro Hernandez <aht@ongres.com>)
Список pgsql-hackers


On Tue, Sep 26, 2017 at 7:42 AM, Alvaro Hernandez <aht@ongres.com> wrote:


On 25/09/17 22:13, Magnus Hagander wrote:
On Mon, Sep 25, 2017 at 8:20 PM, Alvaro Hernandez <aht@ongres.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 :)


--

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Amit Langote
Дата:
Сообщение: Re: [HACKERS] Shaky coding for vacuuming partitioned relations
Следующее
От: Masahiko Sawada
Дата:
Сообщение: Re: [HACKERS] Transactions involving multiple postgres foreign servers