Re: [HACKERS] update_pg_pwd trigger does not work very well

From: wieck(at)debis(dot)com (Jan Wieck)
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Development <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: [HACKERS] update_pg_pwd trigger does not work very well
Date: 2000-02-28 07:34:43
Message-ID: m12PKhX-0003kGC@orion.SAPserv.Hamburg.dsh.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut wrote:

> Tom Lane writes:
>
> > 1. Since the trigger is executed as soon as a tuple is inserted/
> > updated/deleted, it will write pg_pwd before the transaction is
> > committed. If you then abort the transaction, pg_pwd contains wrong
> > data.
>
> Wow, that implies that every trigger that contains non-database
> side-effects is potentially bogus. That never occured to me. Perhaps (as a
> future plan), it would be a good idea to have deferred triggers as well?
> Now that I think of it, wasn't that the very reason Jan had to invent the
> separate constraint triggers?

The reason for the trigger queue was deferrability at all.
And the way it's implemented doesn't help out.

Imagine that the trigger not only affects external data, but
does further checks and/or modifications to table data. If
some statement affects multiple rows, a trigger ran from the
queue can still abort the transaction, but earlier triggers
have already done their external work.

I think some "AT COMMIT EXECUTE function(args)" would be
better. These functions go into a separate queue and shall
not modify any database content any more. At least, it would
restrict cases of external data inconsistency to cases, where
external modifications fail.

> > itself do nothing except set a flag variable. The flag is examined
> > somewhere in xact.c after successful completion of a transaction,
> > and if it's set then we run a new transaction cycle in which we
> > read pg_shadow and write pg_pwd.
>
> If you think that this is okay (and not just a hack), then go for it.

I consider it a hack, since this particular trigger needs a
global flag known explicitly by xact routines. I like general
solutions instead.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck(at)debis(dot)com (Jan Wieck) #

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jan Wieck 2000-02-28 07:42:08 Re: [HACKERS] type coerce problem with lztext
Previous Message Jan Wieck 2000-02-28 07:22:06 Re: [HACKERS] A further thought on rule string size