From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: sql_drop Event Trigger |
Date: | 2013-02-28 17:20:53 |
Message-ID: | 20130228172053.GM9507@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas escribió:
> On Thu, Feb 21, 2013 at 12:52 PM, Alvaro Herrera
> <alvherre(at)2ndquadrant(dot)com> wrote:
> > One funny thing I noticed is that if I add a column in a table being
> > dropped, the targetObjects list does not change after the trigger has
> > run. The reason for this is that the table's attributes are not present
> > in the targetObjects list; instead they are dropped manually by calling
> > DeleteAttributeTuples(). I saw that you can end up with lingering
> > pg_attribute entries that way.
>
> I venture to guess that this is exactly the sort of thing that made
> Tom argue upthread that we shouldn't be putting a firing point in the
> middle of the drop operation. Any slip-ups here will result in
> corrupt catalogs, and it's not exactly future-proof either.
Well, is this kind of thing enough to punt the whole patch, or can we
chalk it off as the user's problem? We can word the docs to state that
we try to detect actions that are known to cause corruption but that
some might slip past, and that it's the user's responsibility to ensure
that the event trigger functions behave sanely.
Another idea I just had was to scan the catalogs after the event trigger
and see if the Xmin for each tuple IsCurrentTransaction(), and if so
throw an error. I think that would be more accurate than the current
implementation, but rather a lot of trouble. I'm open to implementing
that if we consider that idea watertight enough that this patch is
considered commitable.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Jim Nasby | 2013-02-28 17:21:58 | Re: autovacuum not prioritising for-wraparound tables |
Previous Message | Robert Haas | 2013-02-28 16:54:38 | Re: Materialized views WIP patch |