Re: [HACKERS] Proposal: Change of pg_trigger.tg_enabled and adding pg_rewrite.ev_enabled
On Jan 25, 2007, at 5:33 PM, Jan Wieck wrote: A new per session GUC variable, restricted to superusers, will define if the session is in origin or replica mode. It would be nice if we had a separate role for replication services so that we weren't exposing superuser so much. IIRC Oracle even uses 2 roles; one for administration of replication and one that the replication code actually runs under. -- Jim Nasby[EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[HACKERS] Proposal: Change of pg_trigger.tg_enabled and adding pg_rewrite.ev_enabled
The experience with Slony-I has shown that a) different behavior of triggers and rules on a transactions origin and a replica is essential; b) mucking around with the system catalog to achieve this is futile. This would be even more catastrophic in a multimaster environment, where regular transaction origin and replica behavior are required on a per session level concurrently. To achieve the required flexibility, we need to change the definition of the pg_trigger attribute tg_enabled. It currently is a boolean. I would like to change it into a char along with the syntax of ALTER TRIGGER. The value definitions of tg_enabled would be A fires always N fires never O fires on transaction origin only R fires on replica only Anyone preferences how to map that to ALTER TRIGGER? A new per session GUC variable, restricted to superusers, will define if the session is in origin or replica mode. Likewise the system catalog pg_rewrite is extended with an attribute ev_enabled. It will have the same possible values and a new command, ALTER RULE, will match the functionality of ALTER TRIGGER. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Proposal: Change of pg_trigger.tg_enabled and adding pg_rewrite.ev_enabled
Jan Wieck [EMAIL PROTECTED] writes: The value definitions of tg_enabled would be A fires always N fires never O fires on transaction origin only R fires on replica only A new per session GUC variable, restricted to superusers, will define if the session is in origin or replica mode. Are you sure two states are enough? No particular objection, but now would be the time to think if a boolean is sufficient. Likewise the system catalog pg_rewrite is extended with an attribute ev_enabled. It will have the same possible values and a new command, I assume there'd be no intention of supporting on-the-fly changes of this setting (ie, you'd set the GUC variable once at session startup and not change thereafter)? Otherwise you'd have a problem with cached plans. regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Proposal: Change of pg_trigger.tg_enabled and adding pg_rewrite.ev_enabled
Jan Wieck [EMAIL PROTECTED] writes: A fires always N fires never O fires on transaction origin only R fires on replica only 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. Hm, N up there seems easily confused with Normal. Perhaps a less mistake-prone coding would be 1 fires always 0 fires never N fires in Normal mode R fires in Replica mode other letters available for other future mode values? If you consistently think of origin and replica modes then the original proposal is better (using both 0 and O would be Real Bad), but your use of normal and replica in the followup makes me wonder which terminology is more common. regards, tom lane ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate