Re: Event triggers + table partitioning cause server crash in current master

From: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>
To: Mark Dilger <hornschnorter(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Event triggers + table partitioning cause server crash in current master
Date: 2017-05-16 04:37:02
Message-ID: bf6a39a7-100a-74bd-1156-3c16a1429d88@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2017/05/16 1:18, Mark Dilger wrote:
>
>> On May 15, 2017, at 6:49 AM, Mark Dilger <hornschnorter(at)gmail(dot)com> wrote:
>>
>> I can confirm that this fixes the crash that I was seeing. I have read
>> through the patch briefly, but will give it a more thorough review in the
>> next few hours.

Thanks a lot for the review.

> My only negative comment is that your patch follows a precedent of using
> event trigger commands named for AlterTable for operations other than
> an ALTER TABLE command. You clearly are not starting the precedent
> here, as they are already used for IndexStmt and ViewStmt processing, but
> expanding the precedent by using them in DefineRelation, where they were
> not used before, seems to move in the wrong direction. Either the functions
> should be renamed to something more general to avoid implying that the
> function is ALTER TABLE specific, or different functions should be defined
> and used, or ...? I am uncertain what the right solution would be.

Hmm. I think an alternative to doing what I did in my patch is to get rid
of calling AlterTableInternal() from DefineRelation() altogether.
Instead, the required ALTER TABLE commands can be added during the
transform phase, which will create a new AlterTableStmt and add it to the
list of things to be done after the relation is defined. That way,
ProcessUtilitySlow() takes care of doing the event trigger stuff instead
of having to worry about it ourselves. Attached updated patch does that.

PS: actually, we're talking elsewhere [1] of getting rid of adding
explicit NOT NULL constraints on range partition keys altogether, so even
if we apply this patch to fix the bug, there is a good chance that the
code will go away (of course, the bug won't exist too)

I divided the patch into 2 parts.

0001 fixes the bug you reported (not so directly though as my previous
patch did)

0002 fixes the bug I found while working on this, whereby the content of
CreateStmt will become invalid when creating partitions which could
cause crash in certain case

Thanks,
Amit

[1]
https://www.postgresql.org/message-id/8e2dd63d-c6fb-bb74-3c2b-ed6d63629c9d%40lab.ntt.co.jp

Attachment Content-Type Size
0001-Fix-to-make-partitioned-tables-work-with-event-trigg.patch text/x-diff 12.7 KB
0002-Fix-a-bug-of-creating-partitions.patch text/x-diff 1.8 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2017-05-16 06:00:52 Re: [Proposal] Allow users to specify multiple tables in VACUUM commands
Previous Message amul sul 2017-05-16 04:33:06 Re: [POC] hash partitioning