| From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, Marco Slot <marco(at)citusdata(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Onder Kalaci <onder(at)citusdata(dot)com> |
| Subject: | Re: Segfault when creating partition with a primary key and sql_drop trigger exists |
| Date: | 2018-10-04 16:30:27 |
| Message-ID: | 20181004163027.dj6ffjobm2hz2bjk@alvherre.pgsql |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2018-Oct-04, Alvaro Herrera wrote:
> I admit I'm surprised that your patch fixes the bug. sql_drop was added
> before the command-stashing was added for pg_event_trigger_ddl_commands
> was added, and sql_drop only processes objects from the list passed to
> performMultipleDeletions, so adding the EventTriggerAlterTableStart() /
> End() calls should not affect it ... evidently I must be missing
> something here.
I think the explanation for this is that the problem has nothing to do
with sql_drop per se -- it's only that having a sql_drop trigger causes
the event trigger stuff to get invoked, and the bogus code involving
ddl_command_end (the one that's affected by the
EventTriggerAlterTableStart dance) is what crashes.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Khandekar | 2018-10-04 17:29:17 | Re: TupleTableSlot abstraction |
| Previous Message | Dmitry Dolgov | 2018-10-04 16:08:41 | Re: Segfault when creating partition with a primary key and sql_drop trigger exists |