public inbox for [email protected]help / color / mirror / Atom feed
Re: Question on pg_cron 3+ messages / 3 participants [nested] [flat]
* Re: Question on pg_cron @ 2024-06-08 16:23 Ron Johnson <[email protected]> 0 siblings, 1 reply; 3+ messages in thread From: Ron Johnson @ 2024-06-08 16:23 UTC (permalink / raw) To: pgsql-general <[email protected]> On Sat, Jun 8, 2024 at 5:31 AM yudhi s <[email protected]> wrote: > Hello All, > > We have around 10 different partition tables for which the partition > maintenance is done using pg_partman extension. These tables have foreign > key dependency between them. We just called partman.run_maintanance_proc() > through 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 was all working fine and we were seeing the historical partition being > 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? ^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: Question on pg_cron @ 2024-06-08 16:34 yudhi s <[email protected]> parent: Ron Johnson <[email protected]> 0 siblings, 1 reply; 3+ messages in thread From: yudhi s @ 2024-06-08 16:34 UTC (permalink / raw) To: Ron Johnson <[email protected]>; +Cc: pgsql-general <[email protected]> On Sat, 8 Jun, 2024, 9:53 pm Ron Johnson, <[email protected]> wrote: > On Sat, Jun 8, 2024 at 5:31 AM yudhi s <[email protected]> > wrote: > >> Hello All, >> >> We have around 10 different partition tables for which the partition >> maintenance is done using pg_partman extension. These tables have foreign >> key dependency between them. We just called partman.run_maintanance_proc() >> through 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 was all working fine and we were seeing the historical partition being >> 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? > ^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: Question on pg_cron @ 2024-06-09 06:27 sud <[email protected]> parent: yudhi s <[email protected]> 0 siblings, 0 replies; 3+ messages in thread From: sud @ 2024-06-09 06:27 UTC (permalink / raw) To: yudhi s <[email protected]>; +Cc: Ron Johnson <[email protected]>; pgsql-general <[email protected]> On Sat, Jun 8, 2024 at 10:05 PM yudhi s <[email protected]> wrote: > > > On Sat, 8 Jun, 2024, 9:53 pm Ron Johnson, <[email protected]> wrote: > >> On Sat, Jun 8, 2024 at 5:31 AM yudhi s <[email protected]> >> wrote: >> >>> Hello All, >>> >>> We have around 10 different partition tables for which the partition >>> maintenance is done using pg_partman extension. These tables have foreign >>> key dependency between them. We just called partman.run_maintanance_proc() >>> through 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 was all working fine and we were seeing the historical partition >>> being 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? > I believe, You should log this as an issue in the pg_partman open source project. ^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2024-06-09 06:27 UTC | newest] Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2024-06-08 16:23 Re: Question on pg_cron Ron Johnson <[email protected]> 2024-06-08 16:34 ` yudhi s <[email protected]> 2024-06-09 06:27 ` sud <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox