Re: RULE vs TRIGGER

From: Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com>
To: will trillich <will(at)serensoft(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: RULE vs TRIGGER
Date: 2001-07-31 18:05:37
Message-ID: Pine.BSF.4.21.0107311101230.1393-100000@megazone23.bigpanda.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general


On Tue, 31 Jul 2001, will trillich wrote:

> Stephan Szabo wrote:
> >
> > ISTM, in general, the above construct is not safe for general use. Say
> > you have two transactions:
> >
> > Transaction 1 start
> > Transaction 2 start
> > Transaction 1 selects on tbl, gets no rows
> > Transaction 2 selects on tbl, gets no rows
> > Transaction 1 inserts
> > Transaction 2 inserts
>
> aha. boom, integrity check failure. hmm.
>
> > Transaction 1 commits
> > Transaction 2 commits
> >
> > Both transactions would do an insert (not seeing the other) and you'd
> > have two lookup values for the same val. I think you'd need an explicit
> > lock on tbl to make it safe.
>
> is that something that the trigger method manages to
> circumvent somehow? (i presume 'explicit table lock'
> is covered on a page of documentation i haven't run
> across yet...)

I meant using a lock table statement explicitly at the
beginning of the trigger (LOCK TABLE tbl; -- possibly
would have to be through execute, I'm not sure) which
I would presume would mean that the "second" would
have to wait at that point until the first transaction
finished completely. Of course this cuts down your
concurrency as only one transaction calling this would
be able to run and the rest would have to wait.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2001-07-31 18:11:00 Re: looking for a secure
Previous Message Jan Wieck 2001-07-31 17:57:54 Re: Unexpected *ABORT STATE*