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.94.2) (envelope-from ) id 1teaUg-00ERU8-Us for pgsql-general@arkaria.postgresql.org; Sun, 02 Feb 2025 13:58:39 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1teaUd-007M1T-BF for pgsql-general@arkaria.postgresql.org; Sun, 02 Feb 2025 13:58:35 +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.94.2) (envelope-from ) id 1teaUc-007M1L-Tu for pgsql-general@lists.postgresql.org; Sun, 02 Feb 2025 13:58:35 +0000 Received: from mail-wm1-x32c.google.com ([2a00:1450:4864:20::32c]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1teaUZ-002rg9-2V for pgsql-general@lists.postgresql.org; Sun, 02 Feb 2025 13:58:34 +0000 Received: by mail-wm1-x32c.google.com with SMTP id 5b1f17b1804b1-4361f796586so40672885e9.3 for ; Sun, 02 Feb 2025 05:58:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1738504710; x=1739109510; darn=lists.postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=nsvk2X7tCE1MpiAR19I1s0FByyQtCq3ZJluyKPRDpBQ=; b=h0nHGLVkdsU6ZXebyJpcnxwDUIPv9Hlf9o7Grn7cpWST5xktNLaMjRDPMIzwi8VCZt KgVzpQnaQTrOfwM5ocyzgHrJDgIE/7Eliy2NFRcNt07M28J01YyACOT4WmLnMD+bZfOZ Ix1eDOvJaGKE/ApR9lr/QI6JZvJRReLrDzhrP17p0g1Hg2gxGN9f3L4dpBgiZBsexLiP 5YDw1tL419imBeh7j9CSIRl4eh8easbt8HrGQIFrkbK2e/DLvWn22DkUiJUbHETpw8QA 50CLQ/4Iw0WHiTFzZtdIFm7KIf2u1+byO4JGTKarbwebP6OF1L5daFeaZc3ZTy+Y+ggI CYIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738504710; x=1739109510; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=nsvk2X7tCE1MpiAR19I1s0FByyQtCq3ZJluyKPRDpBQ=; b=AJwOdficoSlWt+mJ4w+NkooI5vTZfjkf1HzXP4HRz+Sm9cqKnRib605MsyQPLY1Os6 cYu4ye/7V4tsuO9skM6i4gRyGE1TvT2NcFBnGEk/J2knrNmYtTyIbCkxHcUk8rz+DzPq Omu544o9z8PPRBmkGExEcgDwFYLb0Ki2JhHjzuUDrwEAPp/Lxdus+sVDuS0XQQy8fSc3 abB4rISzjDni/gT5LFNj+zkiBWF4o43UY0QRHJM/NQHZKA0VZWcdjcb5kcNEDEvjZ3fn RkTWiX8jGzre5dOy9CJyqV2X8rgIq0SaDNS6TIeZDmD6qYXcW1DyRe7gYhhy8Ge+DWhE eFvA== X-Gm-Message-State: AOJu0Yz3Y2eyVuJOatH5iuGOj9rVgddgOGi/+KeqdsI8l7wyFQyR1W5B ZCff+X44I8LSOM0ob3VKuHY1Y1eK0ll1PAeFGQaUwGA7KAz/h2qsfcWvAMxRBf28xjienFodgYL R5ZtZRzMpK9FP0VP2Rrn5xAKhrsKP+zuV X-Gm-Gg: ASbGncthhfkxrWY74Nc6OM2aUQH3rm7qrJhSY0jSOFOvFnke8e91C9K6E+mcefZCAj8 7bh387yFhXUoET+yWwyqLqhlIjARkvhnRnj4TIOBQ+IT3MrTu0fzOWIEhuzPOP76nsoRkaeD7 X-Google-Smtp-Source: AGHT+IHe3yn054DyiBR5LMFSG6STqdgYryAyQO1BX0pM52Pjm84NypbDhKOWF6StVanZSqeq7v/Q4q+/80IcY+kIhMc= X-Received: by 2002:a5d:47c2:0:b0:386:1ab5:f0e1 with SMTP id ffacd0b85a97d-38c51950f08mr18784903f8f.14.1738504709871; Sun, 02 Feb 2025 05:58:29 -0800 (PST) MIME-Version: 1.0 From: Shaheed Haque Date: Sun, 2 Feb 2025 13:58:18 +0000 X-Gm-Features: AWEUYZmZiqPsS5mG2J-CKOVpCUve438xh_eEDWpw9EpVzXrMdVvmtO1o7kaeok0 Message-ID: Subject: Idempotent CREATE SUBSCRIPTION and DROP SUBSCRIPTION pair To: pgsql-general list Content-Type: multipart/alternative; boundary="000000000000ac1e8f062d292bf3" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000ac1e8f062d292bf3 Content-Type: text/plain; charset="UTF-8" Hi, For automation purposes, I'd like to identify an idempotent pair of command sequences such that I can CREATE SUBSCRIPTION and DROP SUBSCRIPTION without knowing whether a previous attempt to do either operation partly succeeded or not. Specifically, as per Google and the notes in the docs ( https://www.postgresql.org/docs/current/logical-replication-subscription.html#LOGICAL-REPLICATION-SUBSCRIPTION-SLOT), sometimes, a simple "DROP REPLICATION" is not enough, and one must do something like this: ALTER SUBSCRIPTION $SUBSCRIPTION DISABLE; ALTER SUBSCRIPTION $SUBSCRIPTION SET (slot_name = none); DROP SUBSCRIPTION IF EXISTS $SUBSCRIPTION CASCADE; which of course leaves the slot as the other end, and so when it is to be recreated, "CREATE SUBSCRIPTION" would have to be augmented by "WITH (create_slot=false)". Let's take it as read that network connectivity between the subscribing end and the publication end is OK. Let's say the DROP sequence looked like this: try: DROP SUBSCRIPTION IF EXISTS $SUBSCRIPTION CASCADE; except e: # Optionally, check if the exception e relates to a specific set of errors to do with the slot? ALTER SUBSCRIPTION $SUBSCRIPTION DISABLE; ALTER SUBSCRIPTION $SUBSCRIPTION SET (slot_name = none); DROP SUBSCRIPTION IF EXISTS $SUBSCRIPTION CASCADE; If the exception path were to be taken, then the next CREATE side would have to look something like this try: CREATE SUBSCRIPTION ... except e: # Optionally, check if e relates to a pre-existing slot. CREATE SUBSCRIPTION ... WITH (create_flot=false); Is that the best that can be done? Is there a better way? I'm happy to use SQL, or PL/SQL as needed. Thanks, Shaheed --000000000000ac1e8f062d292bf3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,
For automation purposes, I'd like t= o identify an idempotent pair of command sequences such that I can CREATE S= UBSCRIPTION and DROP SUBSCRIPTION without knowing whether a previous attemp= t to do either operation partly succeeded or not. Specifically, as per Goog= le and the notes in the docs (https://www.postgresql.org/docs/current/logical-replication-subscri= ption.html#LOGICAL-REPLICATION-SUBSCRIPTION-SLOT), sometimes, a simple = "DROP REPLICATION" is not enough, and one must do something like = this:

=C2=A0=C2=A0 =C2=A0 =C2=A0=C2=A0 ALTER SUBSC= RIPTION $SUBSCRIPTION DISABLE;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ALTER SUBSCRI= PTION $SUBSCRIPTION SET (slot_name =3D none);
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 DROP SUBSCRIPTION IF EXISTS $SUBSCRIPTION CASCADE;

=
which of course leaves the slot as the other end, and so when it is to= be recreated, "CREATE SUBSCRIPTION" would have to be augmented b= y "WITH (create_slot=3Dfalse)".

Let= 's take it as read that network connectivity between the subscribing en= d and the publication end is OK. Let's say the DROP sequence looked lik= e this:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 try:
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 DROP SUBSCRIPTION IF EXISTS $SUBSCRIPTION CASCA= DE;
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 except= e:
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 # Optionally, check if the exception e relates to a spec= ific set of errors to do with the slot?
=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ALTER SUBSCRIPTION $= SUBSCRIPTION DISABLE;
=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 ALTER SUBSCRIPTION $SUBSCRIPTION SET (slot_name =3D none);<= br>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 DROP SUB= SCRIPTION IF EXISTS $SUBSCRIPTION CASCADE;
=C2=A0
I= f the exception path were to be taken, then the next CREATE side would have= to look something like this

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 try:
=C2=A0 =C2=A0=C2=A0 = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 CREATE SUBSCRIPTION ...
=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 except e:
=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 # Optionall= y, check if e relates to a pre-existing slot.
=C2=A0 =C2= =A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 CREATE SUBSCRIPTION ..= . WITH (create_flot=3Dfalse);

Is t= hat the best that can be done? Is there a better way? I'm happy to use = SQL, or PL/SQL as needed.

Thanks, Shaheed

--000000000000ac1e8f062d292bf3--