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 1wfG5t-005MPm-2k for pgsql-hackers@arkaria.postgresql.org; Thu, 02 Jul 2026 12:00:38 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wfG5r-001Y6A-0S for pgsql-hackers@arkaria.postgresql.org; Thu, 02 Jul 2026 12:00:35 +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 1wfG5q-001Y61-1z for pgsql-hackers@lists.postgresql.org; Thu, 02 Jul 2026 12:00:34 +0000 Received: from mail-lf1-x136.google.com ([2a00:1450:4864:20::136]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wfG5o-00000001EGK-3Yaw for pgsql-hackers@lists.postgresql.org; Thu, 02 Jul 2026 12:00:33 +0000 Received: by mail-lf1-x136.google.com with SMTP id 2adb3069b0e04-5aeba09900bso1500915e87.2 for ; Thu, 02 Jul 2026 05:00:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1782993631; cv=none; d=google.com; s=arc-20260327; b=lRLuevFYzi4Ywp5mufLL5JiFlCKKTws9piUs4rAVgEY5ctXlBWb29HDwfVAKIGYQ99 wYQRrubsLElTcwsUFtA/J+Wji/iwlE0Pdw3J6IUInapa9rDY7TPtMiIW7+M1m0TdS2IA P8bjyunRlRqCDuTw3VylUuToQNw+2w4uhA9S1R00sbKkAidyKz+g8iCUo4J+lKY/RIqS EWV7NCA8QGR/jIcdGT50hGSk4hzDxhmfR1e/U39Rdyfhv714Wx4PRO9fT/DQM++Bz+mb Xz27lkPUK7y+AyuD8gJn5eiVmMy9jgI4xvwFiRLOQmo6ZtlKIYBZbvlEgx7TgNDYC7/O 9etQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=ul0e+BswgD8MdKvxXgK2YvVJkAGH7WR+tVWYTDpaHV4=; fh=LhHGP0POCauy9QHDz3cFoFYnVKZamQzbnyHz3e55Yqc=; b=V8hY8Bu3TNd//FXB+q38HYE1/H02U63exllTJCt0JirWMrXN6OBECkj/zApnxCtYmN uzl8VfJPAHKssyB+sTLnZF9VtN2eG+PkRFOAeaKKxguwYuvfXRrvzV32yREhQN+aev3X Vv38MW30z73PtyA7vXrxbiuS3RR/nDAr2jnQDpOD6YaBCiJu6lRGAooagqHLXkgtIrtq A4lqF97cFRuwEE3xU/x99CkyxYmiRN7JiZX4EyoCPc9lMABjC0lnEEcOEixlGM+ymnXi Csnux741iN99C8IB1X42vcYvcZ4cve6zZBwg/jItCS5e6zgrpyMoh8FJvFymoa8EcrhC XuvQ==; 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=1782993631; x=1783598431; 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=ul0e+BswgD8MdKvxXgK2YvVJkAGH7WR+tVWYTDpaHV4=; b=i6U9Us2CvdQKKApmj5bQ+IX+zlFDCGAVHvMM618RQc7rXi+fh8dBwep9ZSqt4dXnjF fumoIwI6fAzjuujjhKq5Xi24+KG64DXkRGGcfdm2vcS+dk6C80/jZ71wMHjujhpFFmC4 8qJuDVJBHhFKTeYwX0T58nEma9f4tjIT/tIatZqNfkBlRKgh0rSGg1o03G2CjEKHLHOK b8XqbhsUxJV5HX1zGXlXvdmiE56RSq6NuCFdwOSAINZdrg8l2dmTahohLkmJA3CB4Fmo a5mjU5Stfr0FDT64kAwxg667+QRE74I3t1bc4LTHmDT6EpQaScYVxLtt6vUq1RerBsG7 yv9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782993631; x=1783598431; 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=ul0e+BswgD8MdKvxXgK2YvVJkAGH7WR+tVWYTDpaHV4=; b=hQKoTecHjw9WUCvt0j9s8z5EVDrzDGRXJeXY8laAf4ItIPHFqJvsvaAdZUIOIabZcJ dHe/5O6DPzKR18s7Xx5hAHzjtWcU7xiP9Qxx1QoJwQp2FC+8GPkMRkOEj0JH4Gun18Gl PIUy9cNnGgLrCoayeOORERAQt8uopWvVcpWV/KftPyFmYiBPxCwKswvUGk5aX6FXnEaw SMv33WHjAKu+D6ZSMyvQJ8cqe/+JEjXnt1u0D33E5Dlxqaod9pfAAOPCVMuUn/m1Mnwe hEO8p34Pq+dUkZETnajhDDypqvYNfDwWKUGJ/9ctI7CvMz1Xb6/HiewGsz5/d3zV+u2j xLjw== X-Forwarded-Encrypted: i=1; AHgh+RoFm88WFHEChWht7Wmve5xWgeplbdXWU3jIVLESwdvIVOltJ33XEhcWMjtVkMR8G++APOD3cm58V7oMPzsI@lists.postgresql.org X-Gm-Message-State: AOJu0Yw3k65mEu/4A6oHJa6oRTaVYuE4rSztcazhNmobIPA3nYwcRTpX +LkbbO18PMyFUHdM2P0lenLJZ/OqLYSJqqyCfdyTQJyb0i7EgphUf670ZvGc4m5VvFpsX87QZI8 Dgf2dqRh/9pTgTKozJAZpTyLJHRbYHiw= X-Gm-Gg: AfdE7ckM/553eOSDJLq0PlES07DoC/jc9dA9QIbPz9qjFeQ33v1LrOb+bKi0d3aeqOc ehYkWHFsA7Ki8meMbLlrYtiWSo4/q9VYHpIatoaTIoxVUxDH92lLTXY7ypxMvKHCKgrogM1XHAD iYwHLyGCkqNWZx+dawdOHQ0tCjwD/IC0IxjIfNZGz0lKAorERHkdUeuc7rd6u3Nv6oC2udsOY1T PgUxFdDV70fEFOrOtX2ZbySES8OgfFG/qKu0sxehs4Dw3xqvtnR9m6fEsuWWQuVtwhUqibmXA== X-Received: by 2002:ac2:494f:0:b0:5ae:b25b:1941 with SMTP id 2adb3069b0e04-5aec8036754mr899643e87.49.1782993630457; Thu, 02 Jul 2026 05:00:30 -0700 (PDT) MIME-Version: 1.0 References: From: Dilip Kumar Date: Thu, 2 Jul 2026 17:30:12 +0530 X-Gm-Features: AVVi8Cd8HH2BUKODY_5X5dlRBkILGwqFOUXh7yrg_Utsbnd_2IgGM7rDJGCUxSY Message-ID: Subject: Re: Proposal: Conflict log history table for Logical Replication To: Shlok Kyal Cc: shveta malik , Amit Kapila , Peter Smith , vignesh C , Nisha Moond , Masahiko Sawada , Bharath Rupireddy , PostgreSQL Hackers 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 Thu, Jul 2, 2026 at 4:48=E2=80=AFPM Shlok Kyal wrote: > > On Thu, 2 Jul 2026 at 13:39, Dilip Kumar wrote: > > > > On Wed, Jul 1, 2026 at 6:55=E2=80=AFPM Dilip Kumar wrote: > > > > > > On Wed, Jul 1, 2026 at 1:16=E2=80=AFPM shveta malik wrote: > > > > > > > > On Wed, Jul 1, 2026 at 12:45=E2=80=AFPM Dilip Kumar wrote: > > > > > > > > > > Thanks I have fixed these comments and also merged the docs. > > > > > > > > Thanks. Sharing the version with pgindent run on v61. > > > > > > Here is the updated patch version. It fixes offlist review comments > > > provided by Amit and Shveta, bumps the catversion and adds authors an= d > > > reviewers details. > > > > I rebased the remaining patches on top of HEAD. So far, I have run > > pgindent and completed the doc merge for 0001. The 0002 and 0003 are > > just rebased. > > Hi Dilip, > > While testing I hit the following assert: > + if (OidIsValid(relid)) > + { > + /* Existing table from upgrade */ > + Assert(IsBinaryUpgrade); > + } > > Steps to reproduce: > 1. Suppose initially we have a logical replication setup and the > subscriber is created with 'conflict_log_destination =3D log' > 2. Now we have two psql sessions of the subscriber node. Attach GDB to > first session and add breakpoint to line: > AlterSubscription->LockSharedObject(SubscriptionRelationId, subid, 0, > AccessExclusiveLock); > 3.Execute 'ALTER SUBSCRIPTION sub1 SET (conflict_log_destination =3D > 'all')' on the first session. It will stop at the breakpoint. > 4. Now execute 'ALTER SUBSCRIPTION sub1 SET (conflict_log_destination > =3D 'all');' on the second session. The execution on the second session > is successful and a conflict log table is created. > 5. Continue the execution of the first session. This will hit the > above Assert condition. > > I think this happens because for the first session, we have the stale > copy of 'sub'. > While the first session is stopped at the breakpoint, the second > session successfully executes ALTER SUBSCRIPTION and creates the > conflict log table. When the first session resumes, it still sees the > old value of old_dest (i.e CONFLICT_LOG_DEST_LOG), so > 'opts.conflictlogdest !=3D old_dest' evaluates to true and > 'alter_sub_conflict_log_dest()' is invoked. > Since the second session has already created the conflict log table > and 'want_table' is true, the code finds an existing conflict log > table '(OidIsValid(relid))', causing the assert to fire. In short, if I understand correctly, the issue is that altering a subscription that tries to create the table might hit this assert because we assume that if we are switching from 'log' to 'table' or 'all', there should not be an existing table except in binary upgrade mode. This happens because we read the destination information from subscription cache while checking the table status in real time. In fact in other cases, it might cause alter subscription to error out if the table is created while we are creating the table. Therefore, we need to handle concurrent table creation during ALTER SUBSCRIPTION. One option is: if the table exists and it's not a binary upgrade, should we just error out? --=20 Regards, Dilip Kumar Google