Re: ALTER TABLE ... NOREWRITE option

On 5 December 2012 22:49, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr> wrote:
> Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
>> On 5 December 2012 22:21, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr> wrote:
>>> Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
>>>>> CREATE EVENT TRIGGER my_event_trigger
>>>>> ON table_rewrite
>>>>> EXECUTE PROCEDURE consider_whether_to_throw_an_error();
>>>>
>>>> +1, I was just thinking that myself.
>>>
>>> +1, and I think that can happen for 9.3, as soon as we agree on the list
>>> of code points where we want that event to fire. ALTER TABLE variants
>>> that are rewriting the heap, sure. CLUSTER? VACUUM FULL? TRUNCATE?
>>
>> Events needed
>> * Table rewrite
>> * Index rebuild
>> * Relation scan (index/table/toast etc)
>> * AccessExclusiveLock
>
> For each of those events we need to find the exact code location from
> where to call the registered user defined function, if any. I would like
> us to at least devise which commands are going to fire the events here.
>
> Table Rewrite: ALTER TABLE, CLUSTER, VACUUM… ?
> Index Rebuild: ALTER TABLE, REINDEX, CLUSTER, VACUUM FULL… ?

yes please

> Relation scan: SELECT, ALTER TABLE … ADD CHECK …, etc
>
> maybe targeting index/seq scan from the executor code
> directly would be enough in that case? I'm not sure I
> can call into src/backend/commands/event_trigger.c
> from anywhere in the executor though, I need advice

Not SELECT - DDL only - for things like CREATE INDEX, so IndexBuildScan() IIRC

> AccessExclusiveLock on a relation when taken by *any* command? before
> the lock is taken I suppose…

At end of Lock Acquire, same place we already WAL-log the action.

--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services