extension patch of CREATE OR REPLACE TRIGGER

From: "Osumi, Takamichi" <osumi(dot)takamichi(at)jp(dot)fujitsu(dot)com>
To: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Surafel Temesgen <surafel3000(at)gmail(dot)com>
Subject: extension patch of CREATE OR REPLACE TRIGGER
Date: 2019-02-28 08:43:49
Message-ID: 0DDF369B45A1B44B8A687ED43F06557C010BC362@G01JPEXMBYT03
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: pgsql-hackers

Dear hackers

Hi there !
One past thread about introducing CREATE OR REPLACE TRIGGER into the syntax
had stopped without complete discussion in terms of LOCK level.

The past thread is this. I'd like to inherit this one.
https://www.postgresql.org/message-id/flat/0B4917A40C80E34BBEC4BE1A7A9AB7E276F5D9%40g01jpexmbkw05#39f3c956d549c134474724d2b775399c
Mr. Tom Lane mentioned that this change requires really careful study in this thread.

First of all, please don't forget I don't talk about DO CLAUSE in this thread.
Secondly, Mr. Surafel Temesgen pointed out a bug but it doesn't appear.

Anyway, let's go back to the main topic.
From my perspective, how CREATE OR REPLACE TRIGGER works is,
when there is no counterpart replaced by a new trigger,
CREATE TRIGGER is processed with SHARE ROW EXCLUSIVE LOCK as usual.

On the other hand, when there's,
REPLACE TRIGGER procedure is executed with ACCESS EXCLUSIVE LOCK.

This feeling comes from my idea
that acquiring ACCESS EXCLUSIVE LOCK when replacing trigger occurs
provides data consistency between transactions and protects concurrent pg_dump.

In order to make this come true, as the first step,
I've made a patch to add CREATE OR REPLACE TRIGGER with some basic tests in triggers.sql.

Yet, I'm still wondering which part of LOCK level in this patch should be raised to ACCESS EXCLUSIVE LOCK.
Could anyone give me an advise about
how to protect the process of trigger replacement in the way I suggested above ?

--------------------
Takamichi Osumi

Attachment Content-Type Size
CREATE_OR_REPLACE_TRIGGER_v01.patch application/octet-stream 45.6 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ideriha, Takeshi 2019-02-28 08:48:41 RE: Protect syscache from bloating with negative cache entries
Previous Message Laurenz Albe 2019-02-28 08:33:02 Re: reloption to prevent VACUUM from truncating empty pages at the end of relation