> Generated column is introduced in PG12, and I reproduced generated column problem
in PG12~PG15.
> For dropped column problem, I reproduced it in PG10~PG15. (Logical replication
was introduced in PG10)
So, I'm planning to split the changes into two commits. The first one fixes
for dropped columns, and the second one adds generated columns check/test.
Is that the right approach for such a case?
> and backpatch the fix for dropped column to PG10.
Still, even the first commit fails to apply cleanly to PG12 (and below).
What is the procedure here? Should I be creating multiple patches per version?
Or does the committer prefer to handle the conflicts? Depending on your reply,
I can work on the followup.
I'm still attaching the dropped column patch for reference.
On Thu, Mar 16, 2023 5:23 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Mon, Mar 13, 2023 at 6:26 PM Önder Kalacı <onderkalaci@gmail.com>
> wrote:
> >
> > Attaching v2
> >
>
> Can we change the comment to: "Ignore dropped and generated columns as
> the publisher doesn't send those."? After your change, att =
> TupleDescAttr(slot1->tts_tupleDescriptor, attrnum); is done twice in
> the same function.
>
> In test cases, let's change the comment to: "The bug was that when the
> REPLICA IDENTITY FULL is used with dropped or generated columns, we
> fail to apply updates and deletes.". Also, I think we don't need to
> provide the email link as anyway commit message will have a link to
> the discussion.
>
> Did you check this in the back branches?
>
I tried to reproduce this bug in backbranch.
Generated column is introduced in PG12, and I reproduced generated column problem
in PG12~PG15.
For dropped column problem, I reproduced it in PG10~PG15. (Logical replication
was introduced in PG10)
So I think we should backpatch the fix for generated column to PG12, and
backpatch the fix for dropped column to PG10.
Regards,
Shi Yu