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 1sSA0p-004fYo-96 for pgsql-general@arkaria.postgresql.org; Fri, 12 Jul 2024 06:44:11 +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 1sSA0n-005Wal-TA for pgsql-general@arkaria.postgresql.org; Fri, 12 Jul 2024 06:44:09 +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.94.2) (envelope-from ) id 1sSA0n-005Wab-IG for pgsql-general@lists.postgresql.org; Fri, 12 Jul 2024 06:44:09 +0000 Received: from mail-ed1-x541.google.com ([2a00:1450:4864:20::541]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sSA0l-001f0F-3B for pgsql-general@lists.postgresql.org; Fri, 12 Jul 2024 06:44:08 +0000 Received: by mail-ed1-x541.google.com with SMTP id 4fb4d7f45d1cf-595850e7e11so2066017a12.1 for ; Thu, 11 Jul 2024 23:44:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1720766644; x=1721371444; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=oViItalPhphJbsnNKgqTubRBOtD8yaEnPCpfAbp1Gbg=; b=fvA8OiUJWldWN2lxamyk4//3uJ7R5qEL/7ac9hjAwrQUstYY2+JmpPSsV4BD7zwb4E fpbVuP3rgkR1Zx21UEuM/9S/Wry5jqVXTNAcZHCXPz5K1hnG0u2/OAPm1s6lL0TPIIEA k6op6rLlva4cX3W2i1yPbrKixeWNv7w459+kDKrKDdYrvKeNNekvDB6NWF8MppHzOXx0 mRSFAQGKN3wQFhc1XJEDk89obcsiNQ7nf+7L1jid/D7oBPloXLSDT4Bn+hkpPx5Rokt9 RGgmKI63mUTd9oYglJ6IQ9MAfbhi5E+W9/YODyPmajt6mBHzbtt1kKTDzDC26PT2UJup sWoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720766644; x=1721371444; h=cc:to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=oViItalPhphJbsnNKgqTubRBOtD8yaEnPCpfAbp1Gbg=; b=qR0TGLvcekEtH6SrKr8BMQULFFQKnmMiTmzQkulzkY2n4fkI7pQ6phRHYv42Xh87y+ Pl7ApPnHloP2PRNmNey1sK8Oagj9InjVbhm3N5FNqCsHALunKugU61XxY8pvtaW/AUJP 7S5LpL3rcR4A3LKGthzlq+OSrPYxqI1zmn6cGUHy0EGM7BI0MD5m3xo5NqDdXlhgJ4v2 dXZKBl7dH7zYYXMnBTuiKKr3+h6gOEazHMiJl10mR9fykfzPtWedGSnspJsEdWuUXt0I k1pRvcC5G96i+fTBfCxlb6BZQnwwyrCCJk8gU6TgJY60Hd/pScdZey5HutzSNF9rAUFi gOvQ== X-Gm-Message-State: AOJu0YyvazpTZkgUUJ2RPwZnaBpaJyMqZY3gBMcNmAZJUapceQBzW41L SwxLTvoJ2mhQrg7as+dJ5NnGSDXRmX4CLnBx7uMoOzhuNn0i7pFm9JyX1oVafA2xYfyw0gGn48k dTMoAeSBv/WWKZVt10m7zjKK3XTwseAWBE+c5G6H2X8E= X-Google-Smtp-Source: AGHT+IHczuOkEX+VdeGOEfM9OgaZBvqjmEmWGIfsDxMWDf85pP3FEy3H0l9Zxgu2ZKKpzXct5s1IuTaukhRTFb1Jdss= X-Received: by 2002:a17:906:3ad8:b0:a77:e48d:bb1 with SMTP id a640c23a62f3a-a780b68a2ebmr570511066b.2.1720766643959; Thu, 11 Jul 2024 23:44:03 -0700 (PDT) MIME-Version: 1.0 From: Durgamahesh Manne Date: Fri, 12 Jul 2024 12:15:04 +0530 Message-ID: Subject: Regarding tables detach concurrently with run_maintenance_proc() To: pgsql-general@lists.postgresql.org Cc: keith.fiske@crunchydata.com Content-Type: multipart/alternative; boundary="0000000000008dfdf0061d07341c" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000008dfdf0061d07341c Content-Type: text/plain; charset="UTF-8" Hi Respected Team By default proc() does not detach tables concurrently. How do we implement tables detach concurrently without blocking running sessions in prod. why this is very critical to implement for pg_partman. if this is not available yet on 5.1.0 then when can i expect to get it if already there then please let me know the implementation of detaching tables concurrently Any best way to implement the same please with out concurrently how do we ensure data integrity and consistency Regards Durga Mahesh --0000000000008dfdf0061d07341c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Respected Team

By default=C2=A0proc(= ) does not detach tables concurrently. How do we implement tables detach co= ncurrently without blocking running sessions in prod.
why=C2=A0th= is is very critical to implement for pg_partman.
if this is not a= vailable yet on 5.1.0 then when can i expect to get it=C2=A0
if a= lready there then please let me know the implementation=C2=A0of detaching t= ables concurrently=C2=A0
Any best way to implement the same pleas= e=C2=A0 with out concurrently how do we ensure data integrity and consisten= cy=C2=A0

Regards
Durga Mahesh=C2=A0


--0000000000008dfdf0061d07341c--