Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1w7zUO-0006VL-2e for pgsql-hackers@arkaria.postgresql.org; Wed, 01 Apr 2026 17:36:25 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1w7zUN-001daG-25 for pgsql-hackers@arkaria.postgresql.org; Wed, 01 Apr 2026 17:36:24 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1w7zUN-001da8-0c for pgsql-hackers@lists.postgresql.org; Wed, 01 Apr 2026 17:36:23 +0000 Received: from mail-pf1-x432.google.com ([2607:f8b0:4864:20::432]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1w7zUL-000000002wQ-2pyc for pgsql-hackers@lists.postgresql.org; Wed, 01 Apr 2026 17:36:22 +0000 Received: by mail-pf1-x432.google.com with SMTP id d2e1a72fcca58-82ce0a9b41aso10075b3a.0 for ; Wed, 01 Apr 2026 10:36:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1775064981; cv=none; d=google.com; s=arc-20240605; b=iillNGzpwLjbc6a1YnxwUEHd5ekMX1IiReLKMWIrjHd8S3EQYQpOKcV6VF/WMGJrrQ 2Cm8Qf1bT83KWjAVMMg+RTSit9XSxNp9BREgo3f/eUAJ1UAAHgLejyQ1K+rDWmbut+N3 z+z+vZST0m1q1dzqg5X3d71UUc/vX5OBOpxhhKHs0GsiRx5/zRmqAwRXBFu/UcMKqlJo rK2YdDDJdtlaVea5LyYLpHmu6iHCxm8pD67vslkCTsYQ+o4aoup0vExXYk6xzgC/ypx6 5iWOsXGbhWwiVanmyjr6vytBfZ5ArP/DlyNUfz33uMvKSCPBiIa8XOhrL5DBM7ijeQtX 1Fng== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=N37Lwp1p/JFG1T9QzLZCO5n6bRvhbwB+9pFwktltMpY=; fh=Kn9W5+opeW4d/vJlOXn25/Dwo3NM1+rx1612TB4FMKg=; b=WpvevLKyb96WAUlExfGevaUHvf4JN/r6F6Xp6N0VH9I7hQb353CwpPqBSjOiUoqXUc y4yVBst8+hm/vBVtn3fPY9Rst+3dFK4BUz7lb4jiT26bOtntN7wowMjnP18s5FUgsnT4 5dOsluFdQJmJJ2owxBIJ5HHEAP9Opq5it55qVONJOlrGYH9Ca/A8EF9mdP0LnyUesr13 6VJ9/BkB/3sQ5CE9/s69MV58J6zGnCAvuA8Ll2H820/P88n/o7KKP8lLkpGhYorkBbdn Hm6NWHL3Y8BuG+dD3txyl5gsbz2EhcqBT2ZT7uLZblXUkHJlToUExkziGIMtwpgNPWlH Jh8A==; darn=lists.postgresql.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1775064981; x=1775669781; darn=lists.postgresql.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=N37Lwp1p/JFG1T9QzLZCO5n6bRvhbwB+9pFwktltMpY=; b=ql1jkuTBRlr8LqdhM6XJNtauDCQWUHPfJA3BG7OGWpeNaQCs0guFbZDdrkXWVX5pKC rF8PpE61j0PU/te5ZRr3RHU/ZiNOsCVqw85oMHe8eeTuqlghV6Cc2+QS5/l2Fv/WsFAx S7kwtGzE9SzlynIeJhNv/fKsw8g6/vx1eOqt8ynUTOpplUnJz5q6elEX96gfTl3SpR8u yw/HhlfvwSqyraSj+oN/U/8Ie2UsuM7r6iMQoC2xQDbd64++EP+GkVtzu5jqX0/hoVLk srxBBK0q46NzGuYDKSSf0LFJmdF3GKkib4LbLqGA5DfTGWG4EdlwTJdrznAcx1uTkJL4 STxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775064981; x=1775669781; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=N37Lwp1p/JFG1T9QzLZCO5n6bRvhbwB+9pFwktltMpY=; b=cU3qKQDLg4cNAjFl/YE9mlL2zur5K4vmFTWySazFgei7HqR6f+KorRne2++I7EAsAJ TZMKoCTF/WPR+R+F2uZH8MwVB/P2dmrlJARsn+VzYpg+735wU29m4hmit5Ir1KL1BOyV NwTByJ12qDHT/cQvyaqjyio1+zr5BgTr5toEVkIDHPrVzG/UqHVsTkr5BRj2GZbHMTdS XmSaUqAATDJw8BKFCMsWIhbxJdMljLYBjGvN/PuKY0V+Rzuwzrh2Hyz1RtM82cttfZI/ D09J4NysqNGw86+IjDQE3LkwSaI0/PtgtwtgKBZMmil6A+yfsM6/A/KRFGli//Yha0Pb 00XQ== X-Forwarded-Encrypted: i=1; AJvYcCUV/uJ6hIzxg8Dov9fVKg9Ye6gmlbcLMcGiSl8iWXvfZNF/XV96Sw56vAy88SRCCxgnd2Abc83wgmSLWUYs@lists.postgresql.org X-Gm-Message-State: AOJu0YyfmxXycGzwY0TNscVmFxM0BxLccl1GU/DsDUCa/2D9uzR+vr1h e9pjVR/uCNoeAvjm8ggc12C9Fjzd6q4HcNp0CaZAHdYTOWxxX1HQCSi0RK78yR9clxR2GuhJMnA S6U0c+HI0AmXCI1X8mRc9QvxBD6Q9N60lzXbA X-Gm-Gg: ATEYQzxPTO7AlrgIviwa+KYEuUVEGkYi0LUCeE3juqtDafCMn5ABxN7gQR4XLKCtwr/ czpFYb5aAT+EuCZLxaVVlj2EZxSYBdIimyQAfN1c9J3q+02WMwoLZk3wutTyJGu8GVaBkP1gaQG EXvTGgepv2soXikBPDp800H9JquPWf0WuqJgpLEOxGo9jzNUrjYn9SRThJ5JGSiv6C5FIfPyEqV Uk7zflRNK0h/EN4tI5k7wXrVDQroRhS00g0FmHZG0c/BtMwZ/xMSW8JOYQ0RAzE1qzz+OLFMwAw eQSVWnFS X-Received: by 2002:aa7:88ca:0:b0:81f:ac81:d597 with SMTP id d2e1a72fcca58-82ce86be17dmr5420187b3a.0.1775064980794; Wed, 01 Apr 2026 10:36:20 -0700 (PDT) MIME-Version: 1.0 References: <0c28fbd1-3320-4e9b-815c-6d62753aa063@wi3ck.info> In-Reply-To: From: Masahiko Sawada Date: Wed, 1 Apr 2026 10:35:43 -0700 X-Gm-Features: AQROBzC9LDpIWBGRs6JnHz_QLr-rHFEAm9dFhvMIMedwEmYslPNEwuTnZqUn7x8 Message-ID: Subject: Re: Initial COPY of Logical Replication is too slow To: Amit Kapila Cc: Peter Smith , Jan Wieck , pgsql-hackers@lists.postgresql.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Tue, Mar 31, 2026 at 10:04=E2=80=AFPM Amit Kapila wrote: > > On Tue, Mar 31, 2026 at 10:58=E2=80=AFPM Masahiko Sawada wrote: > > > > On Tue, Mar 31, 2026 at 2:36=E2=80=AFAM Amit Kapila wrote: > > > > > > On Wed, Mar 25, 2026 at 2:19=E2=80=AFPM Peter Smith wrote: > > > > > > > > Hi Swada-San. Here are some minor review comments for v4-0001/2 com= bined. > > > > > > > > =3D=3D=3D=3D=3D=3D > > > > src/backend/catalog/pg_publication.c > > > > > > > > is_table_publishable_in_publication: > > > > > > > > 1. > > > > This function logic has a format like > > > > > > > > if (cond) > > > > { > > > > ... > > > > return; > > > > } > > > > > > > > if (cond2) > > > > { > > > > ... > > > > return; > > > > } > > > > > > > > etc. > > > > > > > > There are many return points, and most of those "if" blocks cannot > > > > fall through (they return). > > > > > > > > I found it slightly difficult to read the code because I kept havin= g > > > > to think, "OK, if we reached here, it means pubviaroot must be fals= e," > > > > or "OK, if we reached this far, then puballtables must be false, an= d > > > > pubviaroot must be false," etc. > > > > > > > > > > I can't say exactly why, but I find it difficult to read this > > > function. So, I share your concerns about the code of this function. > > > Because of its complexity it is difficult to ascertain that the > > > functionality is correct or we missed something. Also, considering it > > > is correct today, in its current form, it may become difficult to > > > enhance it in future. > > > > Okay, I'll refactor that function. > > > > > > > > One more comment on latest patch: > > > * > > > +static Datum > > > +pg_get_publication_tables(FunctionCallInfo fcinfo, ArrayType *pubnam= es, > > > + Oid target_relid, bool filter_by_relid, > > > > > > Why do we need filter_by_relid as a separate parameter? Isn't the > > > valid value of target_relid the same? If so, can't we use target_reli= d > > > for the required checks? > > > > If we don't have filter_by_relid, we would end up not filtering > > anything if users pass 0 (InvalidOid) as the target_relid to the new > > pg_get_publication_tables(). This is the same as the behavior of the > > existing pg_get_publication_tables(), > > > > Isn't that what we want when a user passes InvalidOid? What is the > expected behavior in that case? > While it could be contrivarsial what we expect when "users wants to filter the result by InvalidOid", I think the new pg_get_publication_tables() should not return anything in this case rather than return all table information. I think this behavior is consistent with the case where users pass non-table OID to the function. I don't want to make passing InvalidOid a special case in the new function. Regards, --=20 Masahiko Sawada Amazon Web Services: https://aws.amazon.com