On Mon, Mar 31, 2014 at 5:19 PM, Tom Lane wrote:
> Basically what you need to end up with is
>
> * trigger function has a membership dependency on the extension
>
Yes, the dependency is set up when the trigger function is dynamically
created by using ALTER EXTENSION ... ADD FUNCTION
* pg_trigge
Moshe Jacobson writes:
> I've added the requisite rows to pg_depend, and I know it was correct
> because \dx+ cyanaudit (my extension) now shows all of the triggers.
> However, pg_dump still dumps them, and pg_restore still restores them,
> causing the same errors as I had before.
I don't think
On Mon, Mar 31, 2014 at 4:32 PM, Moshe Jacobson wrote:
> There is a trigger function on the extension's config table that creates
> the trigger functions and installs them (both from the same function). I am
> about to try playing with pg_depend to see if it has the desired effect.
I've added t
On Mon, Mar 31, 2014 at 4:20 PM, Tom Lane wrote:
> I'm suspicious that the problem is exactly lack of pg_depend records ---
> pg_dump/pg_restore relies on those for correct ordering of parallel
> operations. What method are you using to create these triggers (not
> the functions, the per-table p
Alvaro Herrera writes:
> Moshe Jacobson wrote:
>> Even though I mark the trigger *functions *as owned by my extension, the
>> trigger definitions themselves are still dumped by pg_dump and restored by
>> pg_restore. This is a problem when pg_restore is using parallelism (-j),
>> and one thread sta
Moshe Jacobson wrote:
> Even though I mark the trigger *functions *as owned by my extension, the
> trigger definitions themselves are still dumped by pg_dump and restored by
> pg_restore. This is a problem when pg_restore is using parallelism (-j),
> and one thread starts issuing CREATE TRIGGER co
