Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pKB9B-0001Ia-1f for pgsql-hackers@arkaria.postgresql.org; Tue, 24 Jan 2023 04:43:01 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pKB99-00058u-30 for pgsql-hackers@arkaria.postgresql.org; Tue, 24 Jan 2023 04:42:59 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pKB98-00056j-Hw for pgsql-hackers@lists.postgresql.org; Tue, 24 Jan 2023 04:42:58 +0000 Received: from mail-oi1-x22f.google.com ([2607:f8b0:4864:20::22f]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1pKB90-0001ik-Lw for pgsql-hackers@lists.postgresql.org; Tue, 24 Jan 2023 04:42:57 +0000 Received: by mail-oi1-x22f.google.com with SMTP id r132so12303354oif.10 for ; Mon, 23 Jan 2023 20:42:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=0Vh+bMYPxeNeswdaaCGHBfaZJ27VdREz3Mfify9KGew=; b=ShCbYGBRPef8hnIfBKicZ9XYeBg1BmWVmlvrw3MsH5jQnStlqeXm+d2kQ+gQPmcTkY +ICPdnkkQlv7OQV7MzFx+n+TUBYyG5yZPPqFSCO5y39xyy/CxojJgkkW6wYyerrZ5I6m H7yGSnVyx4LFatdOkCViEjcZB3JNJOEA9pbkepnyJ79etg4Lxz8Er5vMDy5dAULNYWeE USC9ntqEEk1YWeu9armLpwsV5SdmkH4kDn3WEvbIZhazv4uA46DUs6YirzScx5sUac5B NLEP7d2arIgLVaAeQ6b7331rSgtf/OvKtQuynxLJBv1um0P8AAMW/Wj50p0WGPYmETKz PiYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=0Vh+bMYPxeNeswdaaCGHBfaZJ27VdREz3Mfify9KGew=; b=XkzaD+fNPXLtNAwYsAe+J1UCL810zJE/e7P/VLYuVgGv11M25BDPR5eMV12lqk6vy6 cxIhia1bTa9ebUl9ALLI7oJ5hNcuDHZBNsErLL+v/x/pI+2R9WOzykQcVqEEREBnRfEg z3yds+/AKQnImR0iv9oryOKE7f0b/IvqTBsEhvlo7auW1HUmpgXyGFgKE8gGpaU8JbgE ZkGZ4YbDDFvCQc9IuH20qdTapDkpmN6LHfbx8PQi/21t6ICZpcA8Xy7CQ6vjsoOs5BM2 X5GbE8k5JGa0bZj97eJnbB8SZsTf/j0wJH/WIhIB3JFQmVyUc9AeEOVHuHtImY3CWPTN DL4w== X-Gm-Message-State: AFqh2koGkhM07S+aGb7jYpLkKJcxPH2tIWeVCwupE70kgpohXJoyD7T6 HjbNLTK8z7yxWau42wzPuE0QCg2+DDk18h/p4IU= X-Google-Smtp-Source: AMrXdXsylQ80SXD6EUsOVXk0URj2ymliemLIUVnG/cr0ySYc01Vl7RzeVpce0+0BmbXJT+7r7B8emFfVqLdKmLTVsMw= X-Received: by 2002:a05:6808:15a:b0:35a:8ab0:70f0 with SMTP id h26-20020a056808015a00b0035a8ab070f0mr1551299oie.272.1674535369630; Mon, 23 Jan 2023 20:42:49 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Amit Kapila Date: Tue, 24 Jan 2023 10:12:37 +0530 Message-ID: Subject: Re: Perform streaming logical transactions by background workers and parallel apply To: Peter Smith Cc: "houzj.fnst@fujitsu.com" , shveta malik , "wangw.fnst@fujitsu.com" , "shiy.fnst@fujitsu.com" , PostgreSQL Hackers , Dilip Kumar , Masahiko Sawada Content-Type: text/plain; charset="UTF-8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Tue, Jan 24, 2023 at 9:13 AM Peter Smith wrote: > > 1. > > IIUC the GUC name was made generic 'logical_replication_mode' so that > multiple developer GUCs are not needed later. > > But IMO those current option values (buffered/immediate) for that GUC > are maybe a bit too generic. Perhaps in future, we might want more > granular control than that allows. e.g. I can imagine there might be > multiple different meanings for what "buffered" means. If there is any > chance of the generic values being problematic later then maybe they > should be made more specific up-front. > > e.g. maybe like: > logical_replication_mode = buffered_decoding > logical_replication_mode = immediate_decoding > For now, it seems the meaning of buffered/immediate suits our debugging and test needs for publisher/subscriber. This is somewhat explained in Shveta's email [1]. I also think in the future this parameter could be extended for a different purpose but maybe it would be better to invent some new values at that time as things would be more clear. We could do what you are suggesting or in fact even use different values for publisher and subscriber but not really sure whether that will simplify the usage. [1] - https://www.postgresql.org/message-id/CAJpy0uDzddK_ZUsB2qBJUbW_ZODYGoUHTaS5pVcYE2tzATCVXQ%40mail.gmail.com -- With Regards, Amit Kapila.