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? 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. regards. -- Kyotaro Horiguchi NTT Open Source Software Center
