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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-hackers by date

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