Re: ALTER TABLE ... NOREWRITE option

On Thu, Dec 6, 2012 at 3:34 PM, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr> wrote:
> I think we need to be solving that problem when we implement new firing
> points for event trigger. The 'table_rewrite' event needs to fire at a
> time when the code can cope with it. That's the main difficulty in
> adding events in that system, asserting their code location safety.

Agreed.

> They need to fire before catalogs are modified, or after, not in
> between, I agree with that. I don't see other ways of implementing that
> than carefully placing the call to user code in the backend's code.

Also agreed.

> The log insert needs to happen either before or after the rewrite, in
> terms of catalog state. I don't see any magic bullet here.

And again agreed.

I think in this case we need to work out before actually doing
anything whether a rewrite will occur, and then remember that
decision. If the decision is yes, then we call the trigger. After
calling the trigger, we need to revalidate that it hasn't invalidated
any critical assumptions upon which we're relying for the sanity of
the system (e.g. the table hasn't been altered or dropped). Assuming
all is well, we then proceed to do the actual operation, basing the
decision as to whether or not to rewrite on the remembered state.

I think ALTER TABLE actually has a lot of this machinery already in
the form of a distinction between "prep" and "exec". However, there
are some cases where the prep work has been folded into the execute
phase (or maybe visca versa). So there may be some code cleanup that
is needed there, or we may need to move some things from the exec
phase to the prep phase to make it all work out. I think it's totally
doable, but it's not going to be a 50-line patch.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company