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 1sOYLH-0000q1-C5 for pgsql-general@arkaria.postgresql.org; Tue, 02 Jul 2024 07:54:23 +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 1sOYLF-0002c8-Di for pgsql-general@arkaria.postgresql.org; Tue, 02 Jul 2024 07:54:22 +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 1sOYLF-0002bz-1b for pgsql-general@lists.postgresql.org; Tue, 02 Jul 2024 07:54:21 +0000 Received: from mail-qv1-xf32.google.com ([2607:f8b0:4864:20::f32]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sOYLD-004CCQ-Dz for pgsql-general@lists.postgresql.org; Tue, 02 Jul 2024 07:54:20 +0000 Received: by mail-qv1-xf32.google.com with SMTP id 6a1803df08f44-6b54683f65fso19912896d6.1 for ; Tue, 02 Jul 2024 00:54:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719906858; x=1720511658; 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=o+wFvQczq4t3HxVbPxv07VNLIp0RvbFajVU7jfM9dvg=; b=W80ti242ol1g+M0Qf6zcElaprYZnl3KLYOnj0iFI8OnyCwLHgpe648pGnewhNzCHoE nYAP0ET9Qyj78YhGBypP6tzpcNNn1et1QEsUm5/E3CD2nmXGQ3YycjBj4mRIu6USuUFp uv/MFKcYZYjnsfZwn55Zg/0WUDQLxMWhoAk57d751vz7wMyKktrvXEwZcLUQ6yD8g2dk CYf7r+KnKp3C4mv/8v8SNmz1LUhJELy2remmHVaRN4GlJa/JPO1gWYh8uFIgTXsOMvJL ki2scpV5f4B7AfrIubnW0eeUCIpACSYWzfDHnXgLgtUSs5GZrFfd8MtygcXNLNsGrcao aevg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719906858; x=1720511658; 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=o+wFvQczq4t3HxVbPxv07VNLIp0RvbFajVU7jfM9dvg=; b=e/17c1ZEqUNOr3KYkpN6oks6Uco8C2eTleSaFVKvKvWgw5LLh/UNK2U0Ja7GNGfUG3 Qn7MqUUG/V60OvLpfewRC1IcSSVxfQQwK1/lfCdH8ZTpo/Fu7AviwpG5WrHQR2q9rFrN x6hlLGQvW+ags6F/a5kqG7NHuB0G07+NCx1AjdqjEsm06lPt+LShXIDPYCbM4cQn2gq/ VW1vmGPKH+U1efh31De2eLOth3uKz5/LGDS5OTkt2UqUbh+LxqWXOG01ooLu4uZA2Lie +s3afBpn/LJmGEGZ51L+ivvExHfEU+qByf10G6k/I0rq0CyrTf3tzcrDC+EmOeRAeNKh Z6Jg== X-Gm-Message-State: AOJu0YwQFU98yv84QJNs2jn64slsrzzTdXf5N4k6OLBIY/55/RCxaWXF nDlNLNm+cW6vSNSAwvZasHazcAq4NHx+VmyIHBjlCp0O/xQn6c9HzVcKyjKwoUPmEWBWSQxrcZG GYJ8KZAf2T8sF78jToa73sr8NDJo= X-Google-Smtp-Source: AGHT+IFT/sq7LNUATQrQSBL3wdXapNwPOJ30Ih12eC/4UBroGQyK+hUwCimQjs7DM9H5R3KIv8yuOPdbta1w+I4MWT8= X-Received: by 2002:ad4:5cec:0:b0:6b5:9c9c:7baf with SMTP id 6a1803df08f44-6b5b70d0f4emr112571136d6.23.1719906858486; Tue, 02 Jul 2024 00:54:18 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: yudhi s Date: Tue, 2 Jul 2024 13:24:07 +0530 Message-ID: Subject: Re: Question on partman extension while relation exist To: Muhammad Ikram Cc: pgsql-general Content-Type: multipart/alternative; boundary="00000000000058d3f8061c3f05af" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --00000000000058d3f8061c3f05af Content-Type: text/plain; charset="UTF-8" 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 by 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 you mean having that with another event trigger which will fire before drop? --00000000000058d3f8061c3f05af Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, 2 Jul, 2024, 12:43 pm Muhammad Ikram,= <mmikram@gmail.com> wrote:<= br>
Hi Yudhi,
I think disabling foreign keys before maintena= nce will help.

--
Muhammad Ikram
=

Do you mea= n to say call the parent table first for maintenance followed by child, and= remove all the foreign key first which are pointing to this parent table p= artition which is going to be dropped by the pg_partman?=C2=A0

As drop/create partition is being ca= lled from within pg_partman without our intervention, so where should we pu= t this drop foreign key code? Do you mean having that with another event tr= igger which will fire before drop?=C2=A0
--00000000000058d3f8061c3f05af--