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

Re: Proposal: Change of pg_trigger.tg_enabled and adding

From: Markus Schiltknecht <markus(at)bluegap(dot)ch>
To: Jan Wieck <JanWieck(at)Yahoo(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Proposal: Change of pg_trigger.tg_enabled and adding
Date: 2007-01-26 11:13:39
Message-ID: 45B9E263.3070808@bluegap.ch (view raw or flat)
Thread:
Lists: pgsql-hackers
Hi,

Nice proposal. I'd support that enhancement and could make use of such 
triggers in Postgres-R as well, at least to provide these triggers to 
the user.

Jan Wieck wrote:
> Good question. I don't know. I'd rather error on the safe side and make 
> it multiple states, for now I only have Normal and Replica mode.

Are these triggers intended to help implement async replication or are 
these for users to be able to take action on remote replay of a 
transaction (i.e. on the replica)? Does that give a further distinction?

In Postgres-R, I mostly use the terms 'local' and 'remote'. Also, 
"normal mode" can easily be confused with "non-replicated" mode, thus 
I'd not mix that with replicated, local transaction mode (even if it's 
mostly equal, as in this case). My naming proposal would thus be:

     A   fires always (i.e. fires N times, where N = nr of nodes)
     L   fires on the transaction local node (i.e. only exactly once)
     R   fires on the remote nodes only (i.e. (N - 1) times)
     0   fires never

'1' for "fires on both nodes" seems confusing as well, because it's not 
like in single node DB operation, in that one event can fire the trigger 
multiple times (on different nodes). The current, single node PostgreSQL 
should thus use '0' or 'L'.

Regards

Markus


In response to

Responses

pgsql-hackers by date

Next:From: Heikki LinnakangasDate: 2007-01-26 12:11:10
Subject: Re: crash on 8.2 and cvshead - failed to add item to the
Previous:From: Hubert FONGARNANDDate: 2007-01-26 11:12:02
Subject: Re: Recursive Queries

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