Postgres Pro
Downloads
Home   >   mailing lists

Re: Assertion failure while streaming toasted data - Mailing list pgsql-hackers

From Pavan Deolasee
Subject Re: Assertion failure while streaming toasted data
Date
Msg-id CABOikdM2UhLTHY4b3zXcSRinz+czbD-6Tucm96VRS4qdmjZagw@mail.gmail.com
Whole thread Raw
In response to Re: Assertion failure while streaming toasted data  (Dilip Kumar <dilipbalaut@gmail.com>)
Responses Re: Assertion failure while streaming toasted data
List pgsql-hackers
Tree view


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

Attachment

pgsql-hackers by date:

Previous
From: "tsunakawa.takay@fujitsu.com"
Date:
Subject: RE: Parallel Inserts in CREATE TABLE AS
Next
From: Paul Guo
Date:
Subject: sync request forward function ForwardSyncRequest() might hang for some time in a corner case?