Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
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.



# 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


pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group