Re: Event Triggers: adding information

Hi,

Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> writes:
> Cool, will prepare a separate patch implementing that API now, and base
> the following patches on top of that. My thinking is to do as following:
>
> - API patch to get Oid from all CREATE/ALTER commands
> - API patch for getting the Oid(s) in (before) DROP commands
> - Event Trigger Infos patch, depending on the previous ones
> - Command String Rewrite and its publishing in Event Triggers
>
> Of course for the DROP parts, we'd better have the Oid and use it before
> the command runs through completion or it will not be usable from the
> event trigger (the target is ddl_command_start in that case).

Please find attached two versions of the same patch implementing added
information for Event Triggers, without any support for command strings
normalizing.

- event_trigger_infos.5.patch.gz
applies on top of current's master branch

- event_trigger_infos_partial.5.patch.gz
applies on top of oid-api.0.patch.gz applied to current's master
branch

I guess you're going to use the partial one, but if you want to run a
quick testing the aggregated patch might make sense.

The way I've been adding schema and object names is to do extra lookups
to the system caches (or the catalogs when we don't have caches), so
that the information is know to be correct in all cases. That means I
had to add a CommandCounterIncrement(), and that the information is only
available when the object actually exists (use ddl_command_trace).

Also, in the DROP case, the extra lookup that happens before the DROP
command is done with a ShareUpdateExclusiveLock, so that the object
doesn't disappear from concurrent activity while we run the User Defined
Trigger. Should we be concerned about deadlock possibilities here when
later the transaction will need to upgrade its Lock?

Given lock upgrade concerns, I guess there's not so much we can do apart
from taking an AccessExclusiveLock from the get go in the case of a DROP
Event Trigger at ddl_command_start, right?

> Are you in a position to contribute those parts to the community?
> Implementing them again then having to support two different variants of
> them does not look like the best use of both our times.

I didn't include new testing in that patch version, waiting for your
answer.

> As decided at the hackers meeting, now is the time to address anything
> controversial, once done we can "return with feedback". So that's my
> goal for this commit fest, concerning the Normalized Command String.
>
> Given your review, I think the way forward is pretty clear now, and my
> plan is as following:
>
> - commit Oid related API changes in this commit fest
> - commit Event Trigger Information changes in this commit fest
> - agree on how to tackle exposing the normalized command string

Including this email now, the first two items are getting addressed
(pending review then commit, at least that's the goal here). Let's not
forget the third point: we need to reach an agreement on how to address
the Command String Normalisation, too.

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support