Re: ON COMMIT actions and inheritance

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Subject: Re: ON COMMIT actions and inheritance
Date: 2018-11-07 00:53:26
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On Tue, Nov 06, 2018 at 07:04:17PM +0900, Amit Langote wrote:
> Agree with keeping it simple. Maybe, we could (should?) document that the
> only ON COMMIT action that works when specified with partitioned parent
> table is DROP (other actions are essentially ignored)?

I have been thinking about this one, and here are some ideas:
When used on a partitioned table or a table with inheritance children,
this drops the depending partitions and children.
When used on a partitioned table, this is not cascaded to its

> Seems fine to me.

Thanks for looking at the patch.

> +
> + /*
> + * Truncate relations before dropping so as all dependencies between
> so as -> so that


> + * relations are removed after they are worked on. This is a waste as it
> + * could be possible that a relation truncated needs also to be removed
> + * per dependency games but this makes the whole logic more robust and
> + * there is no need to re-check that a relation exists afterwards.
> + */
> "afterwords" seems redundant, but may I suggest rewriting the 2nd sentence as:
> Doing it like this might be a waste as it's possible that a relation being
> truncated will be dropped anyway due to it's parent being dropped, but
> this makes the code more robust because of not having to re-check that the
> relation exists.

Your comment sounds better, so added.

Attachment Content-Type Size
on-commit-inh-v3.patch text/x-diff 9.8 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Imai, Yoshikazu 2018-11-07 01:00:17 RE: speeding up planning with partitions
Previous Message Kyotaro HORIGUCHI 2018-11-07 00:31:36 Re: shared-memory based stats collector