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 1veAWQ-009h6t-2H for pgsql-hackers@arkaria.postgresql.org; Fri, 09 Jan 2026 11:19:15 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1veAWP-006odd-0t for pgsql-hackers@arkaria.postgresql.org; Fri, 09 Jan 2026 11:19:14 +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 1veAWO-006odU-2b for pgsql-hackers@lists.postgresql.org; Fri, 09 Jan 2026 11:19:13 +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.96) (envelope-from ) id 1veAWN-0053ai-2w for pgsql-hackers@lists.postgresql.org; Fri, 09 Jan 2026 11:19:12 +0000 Received: by mail-lf1-x136.google.com with SMTP id 2adb3069b0e04-59b685d2b79so4000890e87.3 for ; Fri, 09 Jan 2026 03:19:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1767957550; x=1768562350; 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=nRwnONuldywIaJ2AlAIhv2zeLhwLUoiH/n6OgGSPOZo=; b=JvPoyHrSmHBy0Ou5YurHBkQ2BgHgnw1tcYw81PDNbLlJ7niUnWJ0Gz6bTPc4Tzdj5V ZsRjQqjWAUyijixlkjU2rfGUPgIKOSLTRNneWziMESRYcZkwBPBpZb4hIujaYN1zKwbG hNRHpKP8y7pe4lXB4UwYZqYVZPdSscxyPJ1oSGA+2a0iAB29SQkGn6ytSSiOwvoKk7iI I5chzDjRX5W5TFySxAhx6rCDjX6thEfXczBb7OY54a3TUbMCcq2SDKK4u96vc1gresX9 6EQs/RezNga21IFXDfLoy1/ug3vdsPno5udIIo0h+RUeFkLsLs4TNc3/D1OD0uhpM8fK s2fg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767957550; x=1768562350; 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=nRwnONuldywIaJ2AlAIhv2zeLhwLUoiH/n6OgGSPOZo=; b=oQdx6G0AKpDQVILMMF/TIKFzTyV0k5G7YBQutXKBN9sgenKefVbH9ylaHEsb2Nzu78 55APA8ACcfVVgmH7OJK58e+BD3BR9XE50a6sjVHl3PFYV6NI9MktzSWp10TwtHKNuCJj oqRErQIJ0c3jstywIYrr5U54pVL22eQ92OnwPES99ExSUowfGKcRA4ba73suj9QaaK/l 6K6Ralsyu3xXHhPuOkAuvTJbYG4JkK4GLkmLEiZlbWASplaEPDOkwtiQj+EZ8fGqMocw +HUzuAn0jkWCWQCESsASg0KSYz1ox3PIsF2WrT8ES8d/q7+Tur3dh61HtJh2vfiMofvd DAAg== X-Forwarded-Encrypted: i=1; AJvYcCUs9sJNHGbU6nzNCL3K8OD6YMChKtdEeTU3RVQ1q0uYe2qBuAR5ZIJ0xDbVm8O8N1N63o2kfxbx3HemjGow@lists.postgresql.org X-Gm-Message-State: AOJu0YwCr5lMfG8OM4VJKnrtATlm+6t3MdysDUIuYuRTcegwyCRJJsDO ep46eN1Avf2mfvb6/T9oBho8Q80MtYoGkJmk7PghQjWnlgH2KC4IopsXCu+gUMKk9jM7+0d25bO mzXp6tkj6JQtm+wJqljXpJX5s8J/+fsc= X-Gm-Gg: AY/fxX4xPvrGsUVbEiWdtLdXa49SWFq2cJu23p0FAw+ZxcXRt9k0cHBj33Fem71CJ9T B45kkvGwUUxQm1ejtIZOYPvIMyn9Rm/0W9rGkaQVLG0TVF//kaVdC3NgIUvB5+UGrpsjvKrVWtg p6erF1KRHu5g9APrDlfWci0JQvRO2CXpCbdoZ94HtUqZJILxrbkX4MIq74DWez/XOaIDUvcPJKr HhCJ74SEMfaKUTPrJHGGC51CjTHdxPVtLKqZpxgH8O5gkmJWqa0VFwROIdA9uPF5mJI05bEHb69 qMRmrN51U3AqkraSgEtnSka4tGyP X-Google-Smtp-Source: AGHT+IE+aPIrgQyTF0d2QjpdEqAhUxEB2RaE7z9bTB8fig7B+nMY2G/ULuPu7a9xBwJmv5RVE7Y47It3DxCblPNlQxQ= X-Received: by 2002:a05:6512:3e08:b0:59a:10bb:3c6b with SMTP id 2adb3069b0e04-59b6f01fcdamr3110302e87.18.1767957549668; Fri, 09 Jan 2026 03:19:09 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Dilip Kumar Date: Fri, 9 Jan 2026 16:48:52 +0530 X-Gm-Features: AQt7F2rdN4a4dvvu9i0tW-QvAORNsm0Urif85PWMGPjgsogVlGVaZSxttodJAgk Message-ID: Subject: Re: Proposal: Conflict log history table for Logical Replication To: shveta malik Cc: vignesh C , Amit Kapila , Masahiko Sawada , Bharath Rupireddy , PostgreSQL Hackers , Peter Smith 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, Jan 8, 2026 at 12:30=E2=80=AFPM shveta malik wrote: > > On Wed, Jan 7, 2026 at 12:12=E2=80=AFPM shveta malik wrote: > > > > Hi Dilip, > > Please find a few comments on v19-001: > > > > Please find a few comments for v19-002's part I have reviewed so far: > > 1) > ReportApplyConflict: > + if ((dest & CONFLICT_LOG_DEST_TABLE) !=3D 0) > + if ((dest & CONFLICT_LOG_DEST_LOG) !=3D 0) > > We can use IsSet everywhere IMHO in subscriptioncmd.c we very frequently use the bitwise operation so it has IsSet declared, I am not really sure do we want to define IsSet in this function as we are using it just 2 places. > 2) > GetConflictLogTableInfo > This function gets dest and opens table, shall we rename to : > GetConflictLogDestAndTable Yeah make sense. > 3) > GetConflictLogTableInfo: > + *log_dest =3D GetLogDestination(MySubscription->conflictlogdest); > + conflictlogrelid =3D MySubscription->conflictlogrelid; > + > + /* If destination is 'log' only, no table to open. */ > + if (*log_dest =3D=3D CONFLICT_LOG_DEST_LOG) > + return NULL; > + > + Assert(OidIsValid(conflictlogrelid)); > > We don't need to fetch conflictlogrelid until after 'if (*log_dest =3D=3D > CONFLICT_LOG_DEST_LOG)' check. We shall move it after the 'if' check. Done > 4) > GetConflictLogTableInfo: > + /* Conflict log table is dropped or not accessible. */ > + if (conflictlogrel =3D=3D NULL) > + ereport(WARNING, > + (errcode(ERRCODE_UNDEFINED_TABLE), > + errmsg("conflict log table with OID %u does not exist", > + conflictlogrelid))); > > Shall we replace it with elog(ERROR)? IMO, it should never happen and > if it happens, we should raise it as an internal error as we do for > various other cases. Right, now its internal table so we should make it elog(ERROR) > > 5) > ReportApplyConflict(): > > Currently the function structure is: > > /* Insert to table if destination is 'table' or 'all' */ > if ((dest & CONFLICT_LOG_DEST_TABLE) !=3D 0) > > /* Decide what detail to show in server logs. */ > if ((dest & CONFLICT_LOG_DEST_LOG) !=3D 0) > else > > > It will be good to make it: > > /* > * Insert to table if destination is 'table' or 'all' and > * also log the error msg to serverlog > */ > if ((dest & CONFLICT_LOG_DEST_TABLE) !=3D 0) > {...} > else > {log complete detail} I did not understand this, I mean we can not put the "log complete detail" case in the else part, because we might have to log the complete detail along with the table if the destination is "all", are you suggesting something else? > > 6) > tuple_table_slot_to_indextup_json: > + tuple =3D heap_form_tuple(tupdesc, values, isnull); > > Do we need to do: heap_freetuple at the end? Yeah better we do that, instead of assuming short lived memory context. --=20 Regards, Dilip Kumar Google