Re: Support logical replication of DDLs

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: shveta malik <shveta(dot)malik(at)gmail(dot)com>
Cc: "Zhijie Hou (Fujitsu)" <houzj(dot)fnst(at)fujitsu(dot)com>, vignesh C <vignesh21(at)gmail(dot)com>, Ajin Cherian <itsajin(at)gmail(dot)com>, "Wei Wang (Fujitsu)" <wangw(dot)fnst(at)fujitsu(dot)com>, Runqi Tian <runqidev(at)gmail(dot)com>, Peter Smith <smithpb2250(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, li jie <ggysxcq(at)gmail(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Japin Li <japinli(at)hotmail(dot)com>, rajesh singarapu <rajesh(dot)rs0541(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Zheng Li <zhengli10(at)gmail(dot)com>
Subject: Re: Support logical replication of DDLs
Date: 2023-04-21 09:16:51
Message-ID: CAA4eK1KixJkodJOgLMuW0wxixsTnrNR3MAyxD7_oPyv8B+YgUw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

On Thu, Apr 20, 2023 at 6:09 PM shveta malik <shveta(dot)malik(at)gmail(dot)com> wrote:
>
>
> Few more comments, mainly for event_trigger.c in the patch dated April17:
>
> 1)EventTriggerCommonSetup()
> + pub_funcoid = LookupFuncName(pubfuncname, 0, NULL, true);
>
> This is the code where we have special handling for ddl-triggers. Here
> we are passing 'missing_ok' as true, so shouldn't we check pub_funcoid
> against 'InvalidOid' ?
>

I think so. However, I think this shouldn't be part of the first patch
as the first patch is only about deparsing. We should move this to DDL
publication patch or maybe a separate patch altogether. Another thing
is I feel it is better if this functionality is part of
filter_event_trigger().

>
> 2) EventTriggerTableInitWriteEnd()
>
> + if (stmt->objtype == OBJECT_TABLE)
> + {
> + parent = currentEventTriggerState->currentCommand->parent;
> + pfree(currentEventTriggerState->currentCommand);
> + currentEventTriggerState->currentCommand = parent;
> + }
> + else
> + {
> + MemoryContext oldcxt;
> + oldcxt = MemoryContextSwitchTo(currentEventTriggerState->cxt);
> + currentEventTriggerState->currentCommand->d.simple.address = address;
> + currentEventTriggerState->commandList =
> + lappend(currentEventTriggerState->commandList,
> + currentEventTriggerState->currentCommand);
> +
> + MemoryContextSwitchTo(oldcxt);
> + }
> +}
>
> It will be good to add some comments in the 'else' part. It is not
> very much clear what exactly we are doing here and for which scenario.
>

Yeah, that would be better. I feel the event trigger related changes
should be moved to a separate patch in itself.

--
With Regards,
Amit Kapila.

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Marc Millas 2023-04-21 10:22:52 Re: missing something about json syntax
Previous Message Maxim Boguk 2023-04-21 09:13:32 Unexpectedly huge memory usage (over 180x of work_mem) during hash join... confirmed by TopMemoryContext results (postgresql 13.10)

Browse pgsql-hackers by date

  From Date Subject
Next Message Jelte Fennema 2023-04-21 09:41:50 Re: Reorder connection markers in libpq TAP tests
Previous Message Alexander Lakhin 2023-04-21 09:00:00 Re: Fix typos and inconsistencies for v16