From: | Phil Endecott <spam_from_postgresql_general(at)chezphil(dot)org> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: Triggers, again.. ;-) |
Date: | 2005-02-22 17:14:00 |
Message-ID: | 421B6858.6060107@chezphil.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Tom Lane wrote:
> Phil Endecott <spam_from_postgresql_general(at)chezphil(dot)org> writes:
>
>>It seems less scary when you think of metadata as just being the content
>>of more tables, rather than something special.
>
>
> PG does just fine with handling metadata changes transactionally.
> However, most operations that affect a table's schema at all will take
> an exclusive lock on the table, thereby blocking out other operations
> on the table until the schema-altering operation commits. This could be
> pretty annoying if you have lots of concurrent activity that needs to
> keep going --- in particular the proposed approach would lock out access
> to the underlying table for as long as it takes to update the
> materialized view, since the DROP TRIGGER would take that exclusive lock
> and it'd be held till end of transaction. If that's OK then there's
> nothing wrong with doing it that way.
Hi Tom,
I was hoping that my positive-sounding message would flush out any
problems...
I would understand this if I were doing an "ALTER TABLE", for example.
But does adding or removing a trigger really count as "schema-altering"?
--Phil.
From | Date | Subject | |
---|---|---|---|
Next Message | Craig Bryden | 2005-02-22 17:32:07 | Re: ADO and timestamp/date errors |
Previous Message | Andre Schnoor | 2005-02-22 17:10:38 | Simple client messages from within pgPL/SQL |