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

Re: Proposal: Change of pg_trigger.tg_enabled and adding

From: Chris Browne <cbbrowne(at)acm(dot)org>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Proposal: Change of pg_trigger.tg_enabled and adding
Date: 2007-01-26 16:19:24
Message-ID: 608xfpkbg3.fsf@dba2.int.libertyrms.com (view raw or flat)
Thread:
Lists: pgsql-hackers
markus(at)bluegap(dot)ch (Markus Schiltknecht) writes:
> 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?

Well, there's specific intent, and then there's general intent...  

If I understand correctly (and I think I do), the various threads that
Jan has been starting do have *specific* intent in that he's got an
implementation in mind that would specifically use the features he's
asking about.

But there is also the "general intent" that the features be usable
more widely than that.  If some generalization makes this particular
feature useful for Postgres-R as well as Jan's work, that's better
still.

> 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'.

I rather like your "L" for "local" and "R" for "remote."

An alternative to "A" for "always" would be "B", standing for "runs
[B]oth on local and remote nodes".

Of course, this is picking at nits; the important question is not what
to call the names of the states, but rather whether the set of states
is both desirable and complete...
-- 
select 'cbbrowne' || '@' || 'cbbrowne.com';
http://cbbrowne.com/info/x.html
Rules  of  the Evil  Overlord  #97.  "My  dungeon  cells  will not  be
furnished with  objects that  contain reflective surfaces  or anything
that can be unravelled." <http://www.eviloverlord.com/>

In response to

pgsql-hackers by date

Next:From: Simon RiggsDate: 2007-01-26 16:21:04
Subject: Re: HAVING push-down
Previous:From: Tom LaneDate: 2007-01-26 16:16:23
Subject: Re: HAVING push-down

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