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 1sFz24-0082hO-MX for pgsql-general@arkaria.postgresql.org; Sat, 08 Jun 2024 16:35:09 +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 1sFz22-000GSn-W5 for pgsql-general@arkaria.postgresql.org; Sat, 08 Jun 2024 16:35:07 +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 1sFz22-000GSc-JP for pgsql-general@lists.postgresql.org; Sat, 08 Jun 2024 16:35:07 +0000 Received: from mail-qv1-xf2a.google.com ([2607:f8b0:4864:20::f2a]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sFz1w-000Kky-HP for pgsql-general@lists.postgresql.org; Sat, 08 Jun 2024 16:35:06 +0000 Received: by mail-qv1-xf2a.google.com with SMTP id 6a1803df08f44-6b064841f81so11987646d6.1 for ; Sat, 08 Jun 2024 09:35:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1717864499; x=1718469299; 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=YYlFUm512/EvgaMlkviDrsMTerg3Yr/u6zE/tITkgPo=; b=eBEq8KwNUau6k4mOqTXRQJm4HSMHlfVrH2ZLvxPK/WAibv3LVF8A0bbCCSfd0JR1zW IWtTY9xCegGt9goxMf+eLK+2pHZblX96QqDtjB/RcYssAyWxqekgptpunBkjRoiJgbO0 ATQqQhpSelbIZSKXfTpB+NVqU4RpYVTyLn1o11tqRtdvUBr8H2BrEbsF+jdnEh8wNk4u XuAskcTL/k2ZQFoerS0Ybies6SFv94TniF6qW4hdxlq4dKmda2y6GqEx1rdlRLu9EtU2 TwNFf29V1DYjB1IGCu30wDDgrpTj8UUwhKmpr/HwnAAtVBhuJMcrZEcyuGaLbYexyCfE KSqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717864499; x=1718469299; 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=YYlFUm512/EvgaMlkviDrsMTerg3Yr/u6zE/tITkgPo=; b=YdDiUA5kBser0sdK0ghOn9+bdbqBMoN/icJfJJ7kD6kIlryTpbmwe6bMMPXp7zjPR2 aiiAAbQ9qd/smkSpSQtHiD8TFrUo1Yf8pKEej55+zF93K+yH4efj5gfyP2aydnDROFG7 rDc7DHdcBIkB6sZW7ICzporNFps4nnlwWsxBwoSJTcEUKdiW2qUenDsxMxCt/RkgOj7O hy/vdM3/ksMH6fmG+l4Pp7q6GRug7ttUz+9yH6q6TUP3rlWGfkmnSN80j5QRxS+PlhiA 4cpEdL8NOlm4IrTCMugT+O/lwKdzM1yBBsrowh5UwhBzWNKCC+BbXDwgplYo27KvoiXt U/PA== X-Gm-Message-State: AOJu0Yywg585GeD8Rg72wQ0JD2MQsN+e2RTN33BiETBXyixmOfxLmTlg deMUF0ecDaDYY2EekMcUK8nr6JgWbkpLRApXIIYmkECqL4L7SjavARvlgJJ70YquWDoGo3TQVDd H9uLj/HOUZCQONHoiRhKzoBYb7Y8= X-Google-Smtp-Source: AGHT+IGsyhjKkOHNwT2x6Rt6j9l2HMHt2KZQE+rAicEmpSpk3cmHBMyr0FTa7cPFlyyg+s6UolaLJo0D1lALOl4F8PQ= X-Received: by 2002:a0c:ab05:0:b0:6b0:4201:3840 with SMTP id 6a1803df08f44-6b059f7d218mr46654196d6.40.1717864499363; Sat, 08 Jun 2024 09:34:59 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: yudhi s Date: Sat, 8 Jun 2024 22:04:48 +0530 Message-ID: Subject: Re: Question on pg_cron To: Ron Johnson Cc: pgsql-general Content-Type: multipart/alternative; boundary="00000000000041c923061a637f92" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --00000000000041c923061a637f92 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, 8 Jun, 2024, 9:53 pm Ron Johnson, wrote: > On Sat, Jun 8, 2024 at 5:31=E2=80=AFAM yudhi s > wrote: > >> Hello All, >> >> We have around 10 different partition tables for which the partition >> maintenance is done using pg_partman extension. These tables have foreig= n >> key dependency between them. We just called partman.run_maintanance_pro= c() >> through pg_cron without any parameters and it was working fine. So we ca= n >> see only one entry in the cron.job table. And it runs daily once. >> >> It was all working fine and we were seeing the historical partition bein= g >> dropped and new partitions being created without any issue. But suddenly= we >> started seeing, its getting failed with error "ERROR: can not drop >> schema1.tab1_part_p2023_12_01 because other objects depend on it" >> > > Have you changed version lately of PG, pg_cron or pg_partman? Or maybe > what pg_cron or pg_partman depends on? > No version change, but we updated the part_config to set premake from 30 to 60 for all the tables. But not sure how that impacted this behavior. However, do you think, we should better control the order of execution rather letting postgres to decide it's own, considering there is no such parameters for this ordering in part_config? And in that case which approach should we use out of the two i mentioned. Or any other strategies, should we follow, please advise? > --00000000000041c923061a637f92 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, 8 Jun, 2024, 9:53 pm Ron Johnson, <ronljohnsonjr@gmail.com> wrote:<= br>
O= n Sat, Jun 8, 2024 at 5:31=E2=80=AFAM yudhi s <learnerdatabase9= 9@gmail.com> wrote:
Hello All,

W= e have around 10 different partition tables for which the partition mainten= ance is done using pg_partman extension. These tables have foreign key depe= ndency between them.=C2=A0 We just called partman.run_maintanance_proc() th= rough pg_cron without any parameters and it was working fine. So we can see= only one entry in the cron.job table. And it runs daily once.

It wa= s all working fine and we were seeing the historical partition being droppe= d and new partitions being created without any issue. But suddenly we start= ed seeing, its getting failed with error "ERROR: can not drop schema1.= tab1_part_p2023_12_01 because other objects depend on it"
=C2=A0
Have you changed version lately of PG= , pg_cron or pg_partman?=C2=A0 Or maybe what pg_cron or pg_partman depends = on?

<= div dir=3D"auto">No version change, but we updated the part_config to set p= remake from 30 to 60 for all the tables. But not sure how that impacted thi= s behavior.=C2=A0

Howeve= r, do you think, we should better control the order of execution rather let= ting postgres to decide it's own, considering there is no such paramete= rs for this ordering in part_config? And in that case which approach should= we use out of the two i mentioned. Or any other strategies, should we foll= ow, please advise?=C2=A0
=
--00000000000041c923061a637f92--