Re: Re: [COMMITTERS] pgsql: pg_event_trigger_dropped_objects: Add name/args output columns

I wrote:
> Alvaro Herrera <alvherre@2ndquadrant.com> writes:
>> Alvaro Herrera wrote:
>>> pg_event_trigger_dropped_objects: Add name/args output columns

>> This is causing buildfarm member dunlin to fail:
>> ...
>> No other member so far has reported a problem here.  Not sure if that's
>> the strangest bit, or the fact that dunlin is reporting anything in the
>> first place.  I can reproduce the problem quite simply by creating an
>> event trigger on sql_drop and then try to drop an object not supported
>> by getObjectIdentityParts -- in this case it's a default ACL for tables
>> in the schema being dropped.

> But is there any reason to think the failure on dunlin has anything to do
> with default ACLs?

I substituted a more detailed version of the error message, which soon
confirmed your guess that this had something to do with default ACLs:

http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=treepie&dt=2014-12-31%2021%3A15%3A49

What seems to be happening is that the rowsecurity test installs an event
trigger, and if that happens to be active when the "DROP SCHEMA testns"
in privileges.sql executes, you get a failure because of the default
privileges attached to the schema.  The event trigger is very short-lived,
so the failure is hard to hit; nonetheless this is at least the third such
failure in the buildfarm.

I've "fixed" this by the expedient of making rowsecurity not run as part
of a parallel group.  We cannot have regression tests that trigger such
irreproducible failures.

We should not leave it there though.  The event triggers in rowsecurity
think they only fire for policy-related events, so how come we're seeing
getObjectIdentityParts invoked on a default ACL?  And if that is expected
behavior, how is it you figure it'd be OK to not have an implementation
for every possible object type?

In the long run it might be interesting to have a test module that runs
the entire core regression suite with some appropriate event trigger in
place.  We are clearly far away from being able to do that yet, though,
and in the meantime this is not how I want to find out about event-trigger
bugs.  Creating short-lifespan event triggers has to be something that
happens only in regression tests that run by themselves.
        regards, tom lane