Re: Triggers, again.. ;-)

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.

In response to

Responses

Browse pgsql-general by date

  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