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



---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Reply via email to