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  (Dilip Kumar <dilipbalaut@gmail.com>)
Список 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


--
Pavan Deolasee

Вложения

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

Предыдущее
От: "tsunakawa.takay@fujitsu.com"
Дата:
Сообщение: RE: Parallel Inserts in CREATE TABLE AS
Следующее
От: Paul Guo
Дата:
Сообщение: sync request forward function ForwardSyncRequest() might hang for some time in a corner case?