Re: Reducing lock strength of adding foreign keys

On 10/28/2014 01:33 AM, Noah Misch wrote:
> ALTER TRIGGER is not bad; like you say, change pg_get_triggerdef_worker() the
> way commit e5550d5 changed pg_get_constraintdef_worker(). DROP TRIGGER is
> more difficult. pg_constraint.tgqual of a dropped trigger may reference other
> dropped objects, which calls for equipping get_rule_expr() to use the
> transaction snapshot. That implicates quite a bit of ruleutils.c code.

I started looking into this again and fixed
pg_get_constraintdef_worker() as suggested.

But I have no idea how to fix get_rule_expr() since it relies on doing
lookups in the catcache. Replacing these with uncached lookups sounds
like it could cause quite some slowdown. Any ideas?

Indexes should suffer from the same problems since they too have emay
contain expressions but they seem to solve this by having a higher lock
level on DROP INDEX, but I do wonder about the CONCURRENTLY case.

By the way, unless I am mistaken there is currently no protection
against having a concurrent ALTER FUNCTION ... RENAME mess up what is
dumped in by pg_get_triggerdef().

--
Andreas Karlsson