| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
| Cc: | kuroda(dot)hayato(at)fujitsu(dot)com, amit(dot)kapila16(at)gmail(dot)com, smithpb2250(at)gmail(dot)com, shiy(dot)fnst(at)fujitsu(dot)com, vignesh21(at)gmail(dot)com, shveta(dot)malik(at)gmail(dot)com, osumi(dot)takamichi(at)fujitsu(dot)com, dilipbalaut(at)gmail(dot)com, euler(at)eulerto(dot)com, m(dot)melihmutlu(at)gmail(dot)com, marcos(at)f10(dot)com(dot)br, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Time delayed LR (WAS Re: logical replication restrictions) |
| Date: | 2023-02-16 19:18:42 |
| Message-ID: | 20230216191842.kmeza4vnhal57bng@awork3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 2023-02-16 14:21:01 +0900, Kyotaro Horiguchi wrote:
> I'm not sure why output plugin is involved in the delay mechanism.
+many
The output plugin absolutely never should be involved in something like
this. It was a grave mistake that OutputPluginUpdateProgress() calls were
added to the commit callback and then proliferated.
> It appears to me that it would be simpler if the delay occurred in reorder
> buffer or logical decoder instead.
This is a feature specific to walsender. So the riggering logic should either
directly live in the walsender, or in a callback set in
LogicalDecodingContext. That could be called from decode.c or such.
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2023-02-16 19:29:56 | Re: recovery modules |
| Previous Message | Andres Freund | 2023-02-16 19:11:38 | Re: Add WAL read stats to pg_stat_wal |