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 1wRkgG-002ekg-0g for pgsql-hackers@arkaria.postgresql.org; Tue, 26 May 2026 05:50:20 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wRkgE-0038C5-0e for pgsql-hackers@arkaria.postgresql.org; Tue, 26 May 2026 05:50:19 +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 1wRkgD-0038Bv-2Z for pgsql-hackers@lists.postgresql.org; Tue, 26 May 2026 05:50:18 +0000 Received: from mail-pj1-x1033.google.com ([2607:f8b0:4864:20::1033]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wRkgD-00000000oCF-0H1n for pgsql-hackers@lists.postgresql.org; Tue, 26 May 2026 05:50:17 +0000 Received: by mail-pj1-x1033.google.com with SMTP id 98e67ed59e1d1-3680540a6efso5685134a91.2 for ; Mon, 25 May 2026 22:50:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1779774616; cv=none; d=google.com; s=arc-20240605; b=UlfjXI1vCcMMdkbEHV7iOOV9yxNehg6weup6uCNUsUUkWd0W//8Pqbwm09tHQU21X8 Z1qRrA5krbJgU4K18pkU6RBewR6nEvY4UyGH25UhZrZZLol/13ftzErk44m5hQ+hI2oD H/19gwpCxhkTFdtB1Ik2ZjGKw8bkQiToTW3JjOP8Qga1ydzYA5V4NA0d6iPg/Y+zx+L6 llkHMhS82ru40KLRvDQ46tOXEigGbD3fuuZIFxxgPhdqmAwQbhfjJEaIavZiJfEn1zHl PqDGiGntXtV/0PGKlPX0cvgD7oMlUBCyvoYI7oIar3l3CMTPc4OaN8lcQTeqoX5cOYX2 h8qA== 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=6xhMBOhFchtUosA32x9RD7h68+bikGAzeMww1ZJcg68=; fh=CueX0IHwCmsY+epKoufoetXcLPzd+7bH1W9zrdPbF6o=; b=JAHnlllXhUxdpSnnTdImxKwGfM7KzTQGseKrdEGlgV/RjFAnq4RmNmOi397N+92RdF PZLfHNUHJXgGS0pq53KGP0KME2dOYu14SdEbQF66k0jy1R+aq7zPF7OJUy1ZhZfsq9XS x3IRqCfIEroWPH5AfsP6p1xU3UPttGAn0PtfSwhjyg3ko2hRoMQC/vG4UIRQU8My/n+v Gd1i9H729EjwNj57Ot02h5Pgud+NI5QQiloyZ+5i5Krgyg3D5cyKeCaqcNgLNI4qk9np STwnvoB2I7hbLXnp6Y5vcP8dr1HpxZlyhQyAIFf7TIhxyioHrlCVmoIaN3AnvNP1DMHA UvNA==; 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=1779774616; x=1780379416; 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=6xhMBOhFchtUosA32x9RD7h68+bikGAzeMww1ZJcg68=; b=rPHxY/3UyTkf2UY+YCATqVySQTv+1DYR1bHxR2efbjVhFqdQjfqSN1MjVOCnIWYR8V B/g2uyotbw8PDfqa85s0brDL3iMNn/LcjLjElicmuKdr8hdhHzzVeL1MO52GqYPes7PE OUU+EZ3b/YIcqXaLop6Bur7fvvWCs82LuVKb6u9MtJmXiEskHb/9/+HnDNYL1ZZsUB55 qkCPcYuaB6105gC3HD5fm+416+HEBtyi+HgidxXu0wZaZcDj0HEFRK829ONw/f0rNKyg fPS51EIk5N6GPLWaFg/+GMg+RJA/NTb26uGVdGOmqLSiOvobbeUhK8UaroISZksQ1MTA LLwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779774616; x=1780379416; 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=6xhMBOhFchtUosA32x9RD7h68+bikGAzeMww1ZJcg68=; b=IvCMpzPH6eQqAikDABcNWnJSXm+YQNaLX2rBh+bFXGNa1HRhwVtYjG6HC1jrZ0ijCF i4mtbaqsoodtlLBxpvCfP4FP62jk/iyq0hM/sAVy/X0AFeV0RgXiTeO63IXDi1HkTJY8 BGwQ0+2NWmfSkzm4U8r8EuHJz3oZZ6T4DuJQtPOJn1pOfLnDaAxLc2bJZLWPPkTzA+QN DUqzzA69BUXsGyVb6ixc0jH//ovgq769ZbguloSEEqKoTVxCGqy6V0dVr0zB8MNPs9oT vuOCsQ8h65Tj0LYBBpJQJ2gCjaJYuQG/+yl1UTLBR9iUasKAM5VYyqQ5g037Ik9Rm/RF QDKQ== X-Forwarded-Encrypted: i=1; AFNElJ/pfZZGJ9BicUY5v/B3a/KbLoVZBoqpaIZ+MxvG2eYISEzgiieGYPG8yvZNdlapUQr5CZZJGjuT5RU/Hipv@lists.postgresql.org X-Gm-Message-State: AOJu0YwDneJprzRg3L8hLIKDRZa8lVnp9btp1Qomu+FF7wwBAelENvJs ogHUlW/pTETfz/qjlPvyXDlmkhk1qDdppJe+jq0n2A3vTc109+BLaCzye1hm0Mc7c8VxrltxzRc v+UAwU9Wgdmy/MKNBXgmfRCTBaQTMnKE= X-Gm-Gg: Acq92OGE9sQ/52GDS77KVK7cJr8KT6PB/4D1ND89a5tSPJekx5FMsd76E+9lTGpZmMZ bbymZ5NxjlTR/cTVmOyskJbquhMV/pjmcy3krp35Ys+Xyz2FFxRtEzRAOzjvXity+zf50C18KdH SQfNySed4sKJlHaAqdvsc/niRMpIhfElNHdIapCiIg3AzX65Vr7KHTD1JSRopoSwZTbrfMSre9n D37DS5mAQJDa+SHrtAFdPNnwblG3yb6tsGUDa+6763PToel+2IJ2fzwFY71Ak4cjygP67i7WDX/ n+IRzCOIh4NtpufkgMW7lyGIqcoUq9SBISnYB0zhoahdn3JrPyBl5A== X-Received: by 2002:a17:90b:2d44:b0:368:ea0c:1b6f with SMTP id 98e67ed59e1d1-36a6741d7afmr15583422a91.5.1779774615820; Mon, 25 May 2026 22:50:15 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: shveta malik Date: Tue, 26 May 2026 11:20:03 +0530 X-Gm-Features: AVHnY4LuxDvHMhhjO-7z6aWf1TsnUhGSNQmp3TTUPPTMN9wVrrAJOQf1PSFBogI Message-ID: Subject: Re: [PATCH] Release replication slot on error in SQL-callable slot functions To: SATYANARAYANA NARLAPURAM Cc: vignesh C , Fujii Masao , PostgreSQL Hackers , shveta malik 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, May 26, 2026 at 10:06=E2=80=AFAM shveta malik wrote: > > On Tue, May 26, 2026 at 12:31=E2=80=AFAM SATYANARAYANA NARLAPURAM > wrote: > > > > Hi, > > > > On Mon, May 25, 2026 at 2:58=E2=80=AFAM shveta malik wrote: > >> > >> On Mon, May 25, 2026 at 12:42=E2=80=AFPM SATYANARAYANA NARLAPURAM > >> wrote: > >> > > >> > Hi > >> > > >> > On Fri, May 22, 2026 at 2:16=E2=80=AFAM shveta malik wrote: > >> >> > >> >> Thanks for reporting the issue. I could reproduce the same issue wi= th > >> >> all these as well: > >> >> > >> >> pg_logical_slot_peek_changes > >> >> pg_logical_slot_get_binary_changes > >> >> pg_logical_slot_peek_binary_changes > >> > > >> > > >> > Please find the attached v2 patch that addressed these three cases a= s well. > >> > > >> > >> Thank You for addressuing these cases. A few comments: > >> > >> 1) > >> > >> +-- Test 2: session remains usable after the error (MyReplicationSlot = cleared) > >> > >> It shoudl be part of 'Test 1' itself and thus should not be named as '= Test 2' > >> > >> 2) > >> -------- > >> +-- Test 4: copy_replication_slot with max_replication_slots exceeded. > >> +-- We reduce max_replication_slots artificially by filling all remain= ing slots. > >> +-- Instead, trigger an error by copying to an already-existing name. > >> +DO $$ > >> +BEGIN > >> + PERFORM pg_copy_logical_replication_slot('regression_slot_t3', > >> 'regression_slot_t3'); > >> +EXCEPTION WHEN OTHERS THEN > >> + RAISE NOTICE 'caught: %', SQLERRM; > >> +END; > >> +$$; > >> +-- The original slot must still exist and be usable > >> +SELECT count(*) =3D 1 AS orig_slot_ok FROM pg_replication_slots > >> + WHERE slot_name =3D 'regression_slot_t3'; > >> ----------- > >> > >> I don't think we can hit the Assert with above test (at-least I could > >> not). Since creation of slot itself will fail as the slot with > >> same-name already exists, MyReplicationSlot will never be set and thus > >> Assert will not be hit. A better testcase will be below which fails > >> during LoadOutputPlugin() after slot-creation and MyReplicationSlot is > >> set already. > >> > >> SELECT pg_create_logical_replication_slot('src_slot', 'test_decoding')= ; > >> > >> DO $$ > >> BEGIN > >> PERFORM pg_copy_logical_replication_slot('src_slot', 'dst_slot', > >> false, 'nonexistent_plugin'); > >> EXCEPTION WHEN others THEN > >> RAISE NOTICE 'caught: %', SQLERRM; > >> END $$; > >> > >> SELECT count(*) FROM pg_logical_slot_get_changes('src_slot', NULL, NUL= L); > >> > >> 3) > >> So overall these are the problematic APIs: > >> > >> pg_create_logical_replication_slot > >> pg_replication_slot_advance > >> pg_copy_logical_replication_slot > >> pg_logical_slot_peek_binary_changes > >> pg_logical_slot_peek_changes > >> pg_logical_slot_get_changes > >> pg_logical_slot_get_binary_changes > >> > >> First 3 are are mutually exclusive fixes fow which we have added > >> testcases. Last 4 are addressed by fixing common function > >> pg_logical_slot_get_changes_guts(). I think we should add a test case > >> for at-least any one of these APIs to cover > >> pg_logical_slot_get_changes_guts(). > > > > > > Thanks for reviewing. Please review the attached v3 patch. > > > > A few trivial things: > > 1) > pg_replication_slot_advance: > + PG_TRY(); > + { > + /* Acquire the slot so we "own" it */ > + ReplicationSlotAcquire(NameStr(*slotname), true, true); > + /* A slot whose restart_lsn has never been reserved cannot be advanced = */ > + if (!XLogRecPtrIsValid(MyReplicationSlot->data.restart_lsn)) > > > We can have a blank line after ReplicationSlotAcquire for better readabil= ity. > > 2) > > +SELECT 'init' FROM > pg_create_logical_replication_slot('regression_slot_t3', > 'test_decoding', true); > +SELECT count(*) =3D 1 AS slot_exists FROM pg_replication_slots > + WHERE slot_name =3D 'regression_slot_t3'; > > The intent is not clear why are we checking existence of > regression_slot_t3? I think we can skip it (or else add a comment if > really needed). The success of previous > pg_create_logical_replication_slot is enough to confirm that session > is healthy to run other slot related queries. > > 3) > +SELECT pg_drop_replication_slot('regression_slot_phy'); > + > +-- cleanup > +SELECT pg_drop_replication_slot('regression_slot_t3'); > > We can move drop of 'regression_slot_phy' too under '-- cleanup' > > ~~ > > I have no further comments other than the trivial things mentioned above. > Missed to inform this earlier, I am not able to apply any version of the patches shared so far with 'git am'. It gives error, 'patch -p1' works. git am v3-0001-Release-replication-slot-on-error-in-slot-SQL-functions.patc= h Patch format detection failed. thanks Shveta