At Tue, 28 Feb 2023 08:35:11 +0530, Amit Kapila <amit.kapil...@gmail.com> wrote in > 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.
It looks like the user should decide between potential long locks or extra delays, and this choice ought to be documented. > > 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. I didn't say that to the latest patch. I interpreted the quote of your description as saying that the subscriber-side solution is effective in solving the long-lock problems, so I replied that that can be solved with the publisher-side solution and the subscriber-side solution could cause some unwanted behavior. Do you think we have decided to go with the publisher-side solution? I'm fine if so. regards. -- Kyotaro Horiguchi NTT Open Source Software Center