On Thursday, March 16, 2023 12:30 PM Amit Kapila <amit.kapil...@gmail.com> wrote:
> > On Wed, Mar 15, 2023 at 2:00 PM houzj.f...@fujitsu.com > <houzj.f...@fujitsu.com> wrote: > > > > I noticed that there are some duplicated codes in pgoutput_change() > function > > which can be simplified, and here is an attempt to do that. > > > > For REORDER_BUFFER_CHANGE_DELETE, when the old tuple is missing, after > this patch, we will still send BEGIN and do OutputPluginWrite, etc. > Also, it will try to perform row_filter when none of old_slot or > new_slot is set. I don't know for which particular case we have s > handling missing old tuples for deletes but that might require changes > in your proposed patch. I researched this a bit. I think the old tuple will be null only if the modified table doesn't have PK or RI when the DELETE happens (referred to the heap_delete()), but in that case the DELETE won't be allowed to be replicated(e.g. the DELETE will either error out or be filtered by table level filter in pgoutput_change). I also checked this for system table and in that case it is null but reorderbuffer doesn't forward it. For user_catalog_table, similarily, the DELETE should be filtered by table filter in pgoutput_change as well. So, I think we can remove this check and log. And here is the new version patch which removes that for now. Best Regards, Hou zj
v2-0001-simplify-the-code-in-pgoutput_change.patch
Description: v2-0001-simplify-the-code-in-pgoutput_change.patch
