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 1wcMf0-003IAx-0M for pgsql-hackers@arkaria.postgresql.org; Wed, 24 Jun 2026 12:24:54 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wcMey-000i9c-30 for pgsql-hackers@arkaria.postgresql.org; Wed, 24 Jun 2026 12:24:52 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wcMey-000i9T-1s for pgsql-hackers@lists.postgresql.org; Wed, 24 Jun 2026 12:24:52 +0000 Received: from mail-yx1-xb12e.google.com ([2607:f8b0:4864:20::b12e]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wcMew-000000001VF-1SwK for pgsql-hackers@lists.postgresql.org; Wed, 24 Jun 2026 12:24:52 +0000 Received: by mail-yx1-xb12e.google.com with SMTP id 956f58d0204a3-662dc3879acso781572d50.0 for ; Wed, 24 Jun 2026 05:24:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1782303888; cv=none; d=google.com; s=arc-20240605; b=clwZxrqnMC4GEAk/TZo0pDPVu1dcymor3u9bbbJp717O4G+L7ZZicydtvZatYl01L1 tLYbCUCb8mnGxNMkDv7VW/aMv71lQ+ea2ooj/ISbj2dSCe4rqfNNVPihohlV87MdZcG6 z9J+rKPmwvgxSut448YRFEuy1deyY+NZvEVyq8iTguR+75b5XDaqTyX6p89DxlwcqdPq 6Bt5FgxUwlk26qPaUYNqtCjGgpzUSK1lBt8rhEE4SvG8mIQKpfD+sbXQqAP1pUsYNT6L SKfnI3gvzX5LFdtlZ5G9eH8AFG3p3URZAS7ItjevchTLUYnz07PbWwfQ/T4RrOzLNVeX AlzQ== 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=cnWiMrQ7aosvReOW8yTtEglITef4dbqjO99loqGqNe8=; fh=zOy8fAq6Z0uRE+kjd4VBW62JBkQdQfFuOg7mOFU+y4s=; b=GfLtEgY/7ag3aLRo8ESBxRy6eWI0cJIBqBqP/y6feCbmqOpZS10LDWPJmK2N9jSxHY PspJrSRpSWx2gyWjh4feZGQnAhX/zVhyo5Q7yjgOROVBTVjINaaW90EG1rmyiRkoZDKX 1wKYeHhkf+7WMNLlQTneviTCRPUuKNuHAzyw+WCf2HHPWXPH78v+hlYFGfU9uX3O9/CJ dwjykouMcm4XIcgl72zVhdkynvVlRiBZi1qGJzKo3IgKRJUdwaDPmRT6Jd/D9GOe078J ncEiBTVH5Nh1ZEd7lJgTl2d1H6BtQvp82u15AWQLU1EedSMW4JPkJH7yUUQS1dJGg23B j73Q==; 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=1782303888; x=1782908688; 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=cnWiMrQ7aosvReOW8yTtEglITef4dbqjO99loqGqNe8=; b=jjnSUNBtvgUNpvXy1tOtpRJa+Yyb5QELH2R52gjer+Gh2+VBWkDQpstdglPB3vPKXt AQHRXL29osWc7ih+N4vvRhgOzf8ZjddMo8ChYeHbDgXnhXnpqBSBO5H7kx447Oq4O2rk r7fxFMp3eZL3T1rZEepTVko6nS83ngpIF7yXIQWCt43SOsE1fEs/2kfOibrU12u1FxiP Fe6lun3GBjWHE8M07GlY7KjxRpeRrwiVHUwBh2cfSDd43xsASAVdSAoGsUE6iUn6uI29 0wLPDlVp7ZIUwP7tOTJ7cqZbTaJHEFVqALvfsOE5kXlqPml2BPJOvHm2msmNkA+vAM+1 J0Wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782303888; x=1782908688; 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=cnWiMrQ7aosvReOW8yTtEglITef4dbqjO99loqGqNe8=; b=EZWjK9wygzbWNmYqQZqkMJrjHeJRXWPpR4Vo7AYudRAJp2iIG5wHyUPEM6rUS0zkOr KXsFHeye5bK4G/dDBRHxgGhqY2UyvuPy7bDx/N79GKJzSJuinqHFYnnxTBr/Ac/zh+ly MYkaM0ZSTeMLiRYxk2reKGC2gVgFq8XWzFZtBvzqMh91KWMEREKSoZvY2fJEyFW2cq1+ xB57e9AHk7VaOaqglkA1PtWLPDiSsu66XUbPd2Fqi/KTfzyA/xC1Q/V3WL8cNq8USKfL T0KtuzALwrTXXiMArLJaWYWBMlSYF5DtIUvJKp34RhuZUmF1z4l5OtzHV6LIT7UnJS1r NiEA== X-Forwarded-Encrypted: i=1; AHgh+Rrfz9LZSBUQ9HkfF/ZZjMjFSAZOYQiBt0jQRZRC0w9IZzOfL+awpcJP7Fu4TAlzeiMd7ECiSEqRAFwqzGiJ@lists.postgresql.org X-Gm-Message-State: AOJu0Yy3g5rS5kPnvZDaM7kJ8Y9oW6Xojipan5pttWi8rnlrr/ZLg16e 5001xuL0DIyZWP3bwCxrJ+TrMe5RdnVQbaFl58YtmDa1jqfa4o+yvg/xQtjPAOSntJUiCNjdGFt Uxgv2qZmoDbtBnTNxe5l3Ss7g6g4Osyg= X-Gm-Gg: AfdE7ck0QcLkqdHfzSLk80UPJ/FH4YD2oFOXLKEyQO1Si5w6ESIoPvS/hDd1JSxvIme 5sE0PRE2g8I9koPnceo8/sjoDNqgCHQKU97ZA6Y1Ry6dTwOQAH37c0NC7E71cO1pWUZxx/Ctqsh 4rYckV2aMdOHcTEga24Rle+zQRGlfidLG/w6Oh9lWAOW18/n2u438Q6S8GuMg2MvxWd5KoIJNMw 4vSNj3lEe6zp7LQF1Bq/UKTBPHjmV7Fv9PCxFQrwWcug3KncssnwGn2vnYsd/SFWbpwhQPWeBA= X-Received: by 2002:a05:690e:11ce:b0:661:1be:161b with SMTP id 956f58d0204a3-6636e4f2102mr2718693d50.56.1782303888231; Wed, 24 Jun 2026 05:24:48 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: vignesh C Date: Wed, 24 Jun 2026 17:54:35 +0530 X-Gm-Features: AVVi8CdvEyBpW5pmCbibz8z89F_BNnZupKEL7pMng-mB35SZcR6_V-m8Bg5py6c Message-ID: Subject: Re: Proposal: Conflict log history table for Logical Replication To: Amit Kapila Cc: Dilip Kumar , Nisha Moond , shveta malik , Peter Smith , 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 Wed, 24 Jun 2026 at 16:32, Amit Kapila wrote: > > On Wed, Jun 24, 2026 at 12:53=E2=80=AFPM Dilip Kumar wrote: > > > > On Tue, Jun 23, 2026 at 2:22=E2=80=AFPM vignesh C = wrote: > > > > > > Few comments: > > > 1) Currently we are storing these in shared memory. Looking at the > > > implementation, these fields are purely worker-private state used to > > > ferry data across the error boundary from prepare_conflict_log_tuple(= ) > > > (inside the PG_TRY block) to ProcessPendingConflictLogTuple() (inside > > > the PG_CATCH block). > > Good point. > > If it is not required by another process, should > > > it be moved out of shared memory. > > > + /* A conflict log tuple that is prepared but not yet inserted= . */ > > > + HeapTuple conflict_log_tuple; > > > + > > > + /* > > > + * Error-context string describing the conflict above, used t= o > > > annotate any > > > + * error raised while inserting conflict_log_tuple into the c= onflict log > > > + * table. Allocated, like conflict_log_tuple, in ApplyContex= t. > > > + */ > > > + char *conflict_log_errcontext; > > > > Yeah there is no need for them to be in shared memory, but do we have > > any other data sturcture where these fits naturally, or we can make > > them global variables? > > > > Or we can have a file local struct PendingConflictLogData similar to > FlushPosition. See the attached top-up patch. As the comment > ("Allocated, like conflict_log_tuple, in ApplyContext") says it is > allocated in process-local Apply context, it is not safe to keep them > in shared memory. These approach looks good, couple of minor comments can be done while merging the patch: 1) Generally we keep the typedef name and struct name same: +typedef struct PendingConflictLogData +{ + HeapTuple tuple; /* prepared, not-yet-inserted conflict tuple */ + char *errcontext_str; /* conflict description for error context */ +} PendingConflictLog; 2) PendingConflictLog should be included in typedefs.list Regards, Vignesh