On Tue, Feb 28, 2023 at 8:14 AM Kyotaro Horiguchi <horikyota....@gmail.com> wrote: > > At Mon, 27 Feb 2023 14:56:19 +0530, Amit Kapila <amit.kapil...@gmail.com> > wrote in > > The one difference w.r.t recovery_min_apply_delay is that here we will > > hold locks for the duration of the delay which didn't seem to be a > > good idea. This will also probably lead to more bloat as we will keep > > transactions open for a long time. Doing it before DecodePrepare won't > > I don't have a concrete picture but could we tell reorder buffer to > retain a PREPAREd transaction until a COMMIT PREPARED comes? >
Yeah, we could do that and that is what is the behavior unless the user enables 2PC via 'two_phase' subscription option. But, I don't see the need to unnecessarily delay the prepare till the commit if a user has specified 'two_phase' option. It is quite possible that COMMIT PREPARED happens at a much later time frame than the amount of delay the user is expecting. > If > delaying non-prepared transactions until COMMIT is adequate, then the > same thing seems to work for prepared transactions. > > > have such problems. This is the reason that we decide to perform a > > delay at the start of the transaction instead at commit/prepare in the > > subscriber-side approach. > > It seems that there are no technical obstacles to do that on the > publisher side. The only observable difference would be that > relatively large prepared transactions may experience noticeable > additional delays. IMHO I don't think it's a good practice > protocol-wise to intentionally choke a stream at the receiving end > when it has not been flow-controlled on the transmitting end. > But in this proposal, we are not choking/delaying anything on the receiving end. -- With Regards, Amit Kapila.
