RE: [BUG] Assert failure in ReorderBufferReturnTXN during logical decoding due to leaked specinsert change

Dear Vishal,

Thanks for the patch.

> Found a workload that can reproduce the issue across all supported versions, except PG 14.
>
> For PG 14, since row_filter is not supported, so we can go with the 'publication does not exist' error instead.
> Refer: PG14-Test-specinsert-cleanup-in-ReorderBufferProcessTXN-error-path.patch
>
> For PG 15 - 18, using the row_filter option we can cause an error in the logical decoder.

Per my understanding, for PG16-, the provided workload cannot cause an assertion
failure because it misses the Assert() in the ReorderBufferReturnTXN(), right?
Adding the line is essential, otherwise the test could pass even without the fix.


Below contains more comments. I mainly checked on PG18, so something might not
be suitable for others.

01.
I think it is better to combine tests actual code patches into one. Because they
would be done when patches are committed.

02.
This issue can happen even on HEAD, but PG18-Fix-specinsert... cannot be applied
atop the branch. Can you create it as well?

03. 100_bugs.pl

Other tests start from the comment like "The bug...", but it does not follow.
Can we update?

04. 100_bugs.pl

Can we just rotate a log instead of starting new instance? It might be faster.

05. 100_bugs.pl for PG

```
# The publication row filter WHERE ((a / 0) > 0) will trigger a division by zero error.
```

I think the comment can be improved like:

Create a publication with the zero-division row filter. It always throws an
ERROR before publishing changes, when the filter is evaluated.

Please see attached my top-up patch for PG18, it addresses comments 03-05.


Best regards,
Hayato Kuroda
FUJITSU LIMITED