Re: Not able to purge partition

From: veem v <veema0000(at)gmail(dot)com>
To: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, pgsql-general <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: Not able to purge partition
Date: 2024-03-22 04:47:44
Message-ID: CAB+=1TU5kURyDLHrP4p+CBpniyt-MRemH4jL3zp2oiHebbSLtg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Can someone please confirm if this behavior of foreign key is expected with
the partition created through partman extension and thus we need to have
our manual process written for partition purge (in order of child first and
then parent) , rather relying on partman partition maintenance to take care
drop partition automatically for us?

On Fri, 22 Mar, 2024, 12:42 am veem v, <veema0000(at)gmail(dot)com> wrote:

> On Thu, 21 Mar 2024 at 23:39, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
> wrote:
>
>> On Thu, 2024-03-21 at 22:50 +0530, veem v wrote:
>> > So when you mentioned "to create the foreign keys *not* between the
>> > partitioned table but between the individual partitions" , can that
>> > be done using the same "partman.create_parent" procedure and automated
>> > cron job schedule or has to be done any other way manually ?
>>
>> I don't know the capabilities of partmen, but I would be surprised if
>> it could automatically create foreign keys on the partitions.
>>
>>
> Yes, the constraints on each of the child partitions and parent partitions
> were getting created automatically. As I see from
> information_schema.table_constraints, it shows one foreign key constraint
> in each of the child partitions created through the partman procedure.
>
> It works smoothly without any issue, until we noticed this issue while
> trying to purge the partition from the parent table partition. But I
> believe this extension is extensively used , so I'm just wondering if I am
> missing something here with regards to foreign key creation using this
> automated partition creation/partman extension functionality.
>
>
>

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Daulat 2024-03-22 05:26:31 uncommitted xmin 3100586 from before xid cutoff 10339367 needs to be frozen
Previous Message Tom Lane 2024-03-22 02:07:19 Re: Slow GRANT ROLE on PostgreSQL 16 with thousands of ROLEs