Re: Assertion failure while streaming toasted data
От | Pavan Deolasee |
---|---|
Тема | Re: Assertion failure while streaming toasted data |
Дата | |
Msg-id | CABOikdM2UhLTHY4b3zXcSRinz+czbD-6Tucm96VRS4qdmjZagw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Assertion failure while streaming toasted data (Dilip Kumar <dilipbalaut@gmail.com>) |
Ответы |
Re: Assertion failure while streaming toasted data
|
Список | pgsql-hackers |
On Tue, May 25, 2021 at 1:49 PM Dilip Kumar <dilipbalaut@gmail.com> wrote:
On Tue, May 25, 2021 at 1:45 PM Pavan Deolasee <pavan.deolasee@gmail.com> wrote:
>
> I am not entirely sure if it works correctly. I'd tried something similar, but the downstream node using
> my output plugin gets NULL values for the toast columns. It's a bit hard to demonstrate that with the
> test_decoding plugin, but if you have some other mechanism to test that change with an actual downstream
> node receiving and applying changes, it will be useful to test with that.
Okay, I will test that. Thanks.
I modified test_decoding to print the tuples (like in the non-streamed case) and included your proposed fix. PFA
When the transaction is streamed, I see:
```
+ opening a streamed block for transaction
+ table public.toasted: INSERT: id[integer]:9001 other[text]:'bbb' data[text]:'ccc'
+ table public.toasted: INSERT: id[integer]:9002 other[text]:'ddd' data[text]:'eee'
+ table public.toasted: INSERT: id[integer]:9003 other[text]:'bar' data[text]:unchanged-toast-datum
<snipped>
```
For a non-streamed case, the `data[text]` column shows the actual data. That probably manifests into NULL data when downstream handles it.
Thanks,
Pavan
Вложения
В списке pgsql-hackers по дате отправления: