Обсуждение: Locks under the hood on re-mat and dropping triggers
Dropping triggers from some table yields a lock while a concurrent refresh of a materialized view in another schema entirely is running-- why is this?
--
Wells Oliver
wells.oliver@gmail.com
wells.oliver@gmail.com
On Thu, 2022-05-19 at 14:37 -0700, Wells Oliver wrote: > Dropping triggers from some table yields a lock while a concurrent refresh of a materialized > view in another schema entirely is running-- why is this? That is because dropping a trigger requires a (brief) ACCESS EXCLUSIVE lock on the table, which conflicts with all concurrent access to the table. Yours, Laurenz Albe -- Cybertec | https://www.cybertec-postgresql.com
but what I am seeing is this lock even when the trigger and table are not at all used by an entirely separate mat-view being re-materialized.
On Fri, May 20, 2022 at 12:12 AM Laurenz Albe <laurenz.albe@cybertec.at> wrote:
On Thu, 2022-05-19 at 14:37 -0700, Wells Oliver wrote:
> Dropping triggers from some table yields a lock while a concurrent refresh of a materialized
> view in another schema entirely is running-- why is this?
That is because dropping a trigger requires a (brief) ACCESS EXCLUSIVE lock on the table,
which conflicts with all concurrent access to the table.
Yours,
Laurenz Albe
--
Cybertec | https://www.cybertec-postgresql.com
Wells Oliver
wells.oliver@gmail.com
wells.oliver@gmail.com
Wells Oliver <wells.oliver@gmail.com> writes: > but what I am seeing is this lock even when the trigger and table are not > at all used by an entirely separate mat-view being re-materialized. You'd need to show a test case. Personally I'm wondering if there's a foreign key constraint connecting the troublesome table to some table used by the matview. regards, tom lane