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 1sOqWG-001ZR6-KG for pgsql-general@arkaria.postgresql.org; Wed, 03 Jul 2024 03:18:56 +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 1sOqWE-005iQR-LR for pgsql-general@arkaria.postgresql.org; Wed, 03 Jul 2024 03:18:55 +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 1sOqWE-005iQI-B0 for pgsql-general@lists.postgresql.org; Wed, 03 Jul 2024 03:18:55 +0000 Received: from mail-lj1-x232.google.com ([2a00:1450:4864:20::232]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sOqW9-0009S8-7j for pgsql-general@lists.postgresql.org; Wed, 03 Jul 2024 03:18:54 +0000 Received: by mail-lj1-x232.google.com with SMTP id 38308e7fff4ca-2ee794ec046so11689371fa.2 for ; Tue, 02 Jul 2024 20:18:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719976728; x=1720581528; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=cjWzGa11+vMlC3B9f8Y37bC2KaFmLkovE8zSCFQ4S38=; b=L/lBqXm3qDtIFPECoRBfpWGtHg6qJGYeJryNh6lE0LJtLxovBs4NO6WcViyaegYKma kzkQ21qezZzOUCEXcxJ1o1zKUCPaT8wG4v5pfttWuWX9F5ozNY5V4eMCiEZgdJlSgKFS FennaSMXAZVTXXjJmgz7OqD09tIaxBYRbA/dzGlfYXb0e+ckjQhf+COVbpT8tHP8pMdM 6doeWGIEPSTQMcUuHlas4IGo48atCWcOMtKXH1e1KxiQ+Q7C6VF++qa48ULXzmRL60UA rCBY46KUJqjFWsd8dbuhfE8whm0irI+LFwJ7XT8vLxXmECTroeprhJ+bCN3gHe8WGcW3 WB5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719976728; x=1720581528; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=cjWzGa11+vMlC3B9f8Y37bC2KaFmLkovE8zSCFQ4S38=; b=Inmn11m2YXBwmiyG4aYB7FuHDAqmYfPDxDqzcYyOcHpuXLdfnMFkw/5dqbtjmYVHXB 90fgW50sWJXg4N0QHxBshewXgA7eAuqnnbxjLmJqOr6/bFhOJatUq/+vdqfEuehG7B/c orAhPz8dX13EeeBXYByUKi8vUGXY7loNKb3wXwJVbRrZ1wB2OW89dccKlCGTXeNK7nS0 hDYJmE5hhHwQYIrH10WQP7ZtpAl3Y1LlrcW5kiILYuQsnRipNbbjk4htgfMeq8bYADjf WHCiHLxPndWch0sTjOnMMsFMTJD6pT8MCz5iQxVXi8l1ztziTzR9CXZ8BcvlmBxW5TSH Sc1g== X-Gm-Message-State: AOJu0Yy9PxCF1Z7GOqfj0vMrAsRb3AObks1AczHHufGlZ9RL0TGoQspG 2murc+QF1BpPw7W+rDcWPDPHqtc9809Bz2/FAGJJI0EP2Qdobn0N/ZnqIOMrzpBaorgBLX1fNOJ 7Y1MT8Tgg5kSeVObIWuBWfQahy6hpz+oI X-Google-Smtp-Source: AGHT+IG00mx3CtPqXtR7CVkAoZA3rrceUKkCUOlYuFkP5XSI0USJNtAuEoojwnKvgsrLM39Aw6Asl6+Nij/zUiapTEY= X-Received: by 2002:a05:651c:2113:b0:2ec:52f8:17ad with SMTP id 38308e7fff4ca-2ee5e6f7913mr75046621fa.45.1719976727628; Tue, 02 Jul 2024 20:18:47 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Muhammad Ikram Date: Wed, 3 Jul 2024 08:18:27 +0500 Message-ID: Subject: Re: Question on partman extension while relation exist To: yudhi s Cc: pgsql-general Content-Type: multipart/alternative; boundary="000000000000df52ff061c4f49b3" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000df52ff061c4f49b3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Sorry for late reply, I think you will having some script that drops and creates daily partitions etc, command for disabling/removing any constraint can be placed before these statements so that when the script runs it does the needful. Regards, Muhammad Ikram Bitnine global On Tue, Jul 2, 2024 at 12:54=E2=80=AFPM yudhi s wrote: > > > On Tue, 2 Jul, 2024, 12:43 pm Muhammad Ikram, wrote: > >> Hi Yudhi, >> >> I think disabling foreign keys before maintenance will help. >> >> -- >> Muhammad Ikram >> > > Do you mean to say call the parent table first for maintenance followed b= y > child, and remove all the foreign key first which are pointing to this > parent table partition which is going to be dropped by the pg_partman? > > As drop/create partition is being called from within pg_partman without > our intervention, so where should we put this drop foreign key code? Do y= ou > mean having that with another event trigger which will fire before drop? > --=20 Muhammad Ikram --000000000000df52ff061c4f49b3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

=C2=A0Sorry for late reply, I think you w= ill having some script that drops and creates daily partitions etc, command= for disabling/removing any constraint can be placed before these statement= s so that when the script runs it does the needful.

Regards,
Muhammad Ikram
Bitnine global

=

On Tue, Jul 2, 2024 at 12:54=E2=80=AFPM yudhi s <learnerdatabase99@gmail.com> wro= te:


On Tue, 2 Jul, 2024, 12:43 pm Muhammad Ikram, <mmikram@gmail.com> w= rote:
Hi Yudhi,

I think disabling for= eign keys before maintenance will help.

--
Muhammad Ikram

Do you mean to say call the parent table first for maintenan= ce followed by child, and remove all the foreign key first which are pointi= ng to this parent table partition which is going to be dropped by the pg_pa= rtman?=C2=A0

As drop/cre= ate partition is being called from within pg_partman without our interventi= on, so where should we put this drop foreign key code? Do you mean having t= hat with another event trigger which will fire before drop?=C2=A0


--
Muhammad Ikram

--000000000000df52ff061c4f49b3--