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 1p2kQU-0001Pw-T0 for pgsql-hackers@arkaria.postgresql.org; Wed, 07 Dec 2022 02:44:50 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1p2kQT-0008HS-EC for pgsql-hackers@arkaria.postgresql.org; Wed, 07 Dec 2022 02:44:49 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1p2kQT-0008Eq-2t for pgsql-hackers@lists.postgresql.org; Wed, 07 Dec 2022 02:44:49 +0000 Received: from mail-yw1-x1130.google.com ([2607:f8b0:4864:20::1130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1p2kQO-0007X8-Qs for pgsql-hackers@lists.postgresql.org; Wed, 07 Dec 2022 02:44:48 +0000 Received: by mail-yw1-x1130.google.com with SMTP id 00721157ae682-3bf4ade3364so172534507b3.3 for ; Tue, 06 Dec 2022 18:44:44 -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=Tq8OCRr/aqlcUj8d0BuFoK+bO3HcxamLdR9KNMAwB4s=; b=qNgOBNXATuNIq+ouMhDRvcj2isaVHzbxl0oKCskddxXgReKBi/tFR6z9eZtf624CdS LIbLSdnAFRzYZo4yPVoyhjAOM3dCLeMRT38tpCNDrqHsU8dL27v/qGTB8DKPx3uvw4VS F8nZTuJhdc4m9cXalfEjtZdtfNkDpe+gNcg/MKBnzYJO1oifSFJy8QDCvl9stTQWaBaX pBerG5p+I7ZhWqxRxKR5e1o4zlCmhkmhEvdQ9/JriT7sCjVpd9Vf7iBVJKdPUM4nKT1g tIUj2yVJWYZaQcXAsZFDRbwfO6z0pqQMvFExH20AwwYMXrxgYGLTIt1D0eXoDttUcuyc m7IQ== 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=Tq8OCRr/aqlcUj8d0BuFoK+bO3HcxamLdR9KNMAwB4s=; b=cUYZ8HzdnQ7Sr6Fy6IbZOLitA5K3PxwaIMkzGTEduHWIRFSZQNkpz68j0t2Ro3wyfH jhxikcsq/dtCEWr3VLw6TL4Qd8BqqyU8mLpPCdRP09yIcxLHiFmneW1DjYJqLVgrNsvE 893ohKp8clOoDGWiJxxg4UToizu+NxXku7sHHPgyOUxd+wskytPJaCgxOL67e48AV3NS MMF4q1cymPxa5kwgUDv8rNAQYhg1emmpVjQssSsOQWoY1vtYzcNexGh9BG9iyUhYT7zw A09C6z2sy8QIwdtHnx/mFDFbFY7JZ/3gEqbqnoNK4SE91lxZ80JR36AuRdpobIA9PkPN Ps/A== X-Gm-Message-State: ANoB5pm9MKNUc1YFUslIlgyTbw67rE+pSilNJvh/ZZ9fvR2cT92er/pR ytQ7XgKaaXk7RbExGVmc+P7EvM9Q7v2tS4oXWe0= X-Google-Smtp-Source: AA0mqf7skjDkyn/kaF+mGDLGNJmcAyhXozLU7VEXkpzWjnNV90gQIP0A36GE3Y4EvClZk/CGC77pDX+ZGA8JDXv0xt0= X-Received: by 2002:a81:7056:0:b0:329:88ec:ba20 with SMTP id l83-20020a817056000000b0032988ecba20mr20126309ywc.492.1670381082933; Tue, 06 Dec 2022 18:44:42 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Amit Kapila Date: Wed, 7 Dec 2022 08:14:32 +0530 Message-ID: Subject: Re: Force streaming every change in logical decoding To: Masahiko Sawada Cc: "shiy.fnst@fujitsu.com" , PostgreSQL Hackers 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, Dec 6, 2022 at 7:18 PM Masahiko Sawada wrote: > > On Tue, Dec 6, 2022 at 7:29 PM Amit Kapila wrote: > > > > On Tue, Dec 6, 2022 at 11:53 AM shiy.fnst@fujitsu.com > > wrote: > > > > > > Hi hackers, > > > > > > In logical decoding, when logical_decoding_work_mem is exceeded, the changes are > > > sent to output plugin in streaming mode. But there is a restriction that the > > > minimum value of logical_decoding_work_mem is 64kB. I tried to add a GUC to > > > allow sending every change to output plugin without waiting until > > > logical_decoding_work_mem is exceeded. > > > > > > This helps to test streaming mode. For example, to test "Avoid streaming the > > > transaction which are skipped" [1], it needs many XLOG_XACT_INVALIDATIONS > > > messages. With the new option, it can be tested with fewer changes and in less > > > time. Also, this new option helps to test more scenarios for "Perform streaming > > > logical transactions by background workers" [2]. > > > > > > > Yeah, I think this can also help in reducing the time for various > > tests in test_decoding/stream and > > src/test/subscription/t/*_stream_*.pl file by reducing the number of > > changes required to invoke streaming mode. > > +1 > > > Can we think of making this > > GUC extendible to even test more options on server-side (publisher) > > and client-side (subscriber) cases? For example, we can have something > > like logical_replication_mode with the following valid values: (a) > > server_serialize: this will serialize each change to file on > > publishers and then on commit restore and send all changes; (b) > > server_stream: this will stream each change as currently proposed in > > your patch. Then if we want to extend it for subscriber-side testing > > then we can introduce new options like client_serialize for the case > > being discussed in the email [1]. > > Setting logical_replication_mode = 'client_serialize' implies that the > publisher behaves as server_stream? or do you mean we can set like > logical_replication_mode = 'server_stream, client_serialize'? > The latter one (logical_replication_mode = 'server_stream, client_serialize'). The idea is to cover more options with one GUC and each option can be used individually as well as in combination with others. -- With Regards, Amit Kapila.