Jan Wieck wrote:
> On 1/25/2007 7:33 PM, Tom Lane wrote:
> >
> > 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 cons
On 2/3/2007 5:25 PM, Joshua D. Drake wrote:
Jan Wieck wrote:
Attached is the implementation of the proposed changes as a patch for
discussion.
The chosen syntax is backward compatible and uses
ALTER TABLE ENABLE TRIGGER (fires on origin - default)
ALTER TABLE DISABLE TRIGGER (disabled)
ALT
Jan Wieck wrote:
> Attached is the implementation of the proposed changes as a patch for
> discussion.
>
> The chosen syntax is backward compatible and uses
>
> ALTER TABLE ENABLE TRIGGER (fires on origin - default)
> ALTER TABLE DISABLE TRIGGER (disabled)
> ALTER TABLE ENABLE REPLICA TRIGGE
Attached is the implementation of the proposed changes as a patch for
discussion.
The chosen syntax is backward compatible and uses
ALTER TABLE ENABLE TRIGGER (fires on origin - default)
ALTER TABLE DISABLE TRIGGER (disabled)
ALTER TABLE ENABLE REPLICA TRIGGER (fires on replica only)
ALTE
On Jan 26, 2007, at 5:09 PM, Tom Lane wrote:
Jan Wieck <[EMAIL PROTECTED]> writes:
On 1/26/2007 4:40 PM, Jim Nasby wrote:
It would be nice if we had a separate role for replication services
so that we weren't exposing superuser so much.
So you think about another flag in pg_shadow? Would wor
Hi,
Jim Nasby wrote:
Note that those terms only make sense if you limit yourself to thinking
the master is pushing data out to the slave...
I don't really get the "limitation" here. It's all about distinguishing
between master/slave, origin/replica, local/remote - however you want to
call it
On 1/26/2007 5:09 PM, Tom Lane wrote:
Jan Wieck <[EMAIL PROTECTED]> writes:
On 1/26/2007 4:40 PM, Jim Nasby wrote:
It would be nice if we had a separate role for replication services
so that we weren't exposing superuser so much.
So you think about another flag in pg_shadow? Would work for
Jan Wieck <[EMAIL PROTECTED]> writes:
> On 1/26/2007 4:40 PM, Jim Nasby wrote:
>> It would be nice if we had a separate role for replication services
>> so that we weren't exposing superuser so much.
> So you think about another flag in pg_shadow? Would work for me.
How exactly would such a rol
Jan Wieck <[EMAIL PROTECTED]> writes:
> On 1/26/2007 4:39 PM, Jim Nasby wrote:
>> Also, if enums will be in 8.3, perhaps they can be used instead of
>> "char"?
> I don't like this one. It makes it impossible to provide patches,
> enabling this replication system on older Postgres releases. And
On 1/26/2007 4:47 PM, Jan Wieck wrote:
On 1/26/2007 4:39 PM, Jim Nasby wrote:
On Jan 26, 2007, at 5:13 AM, Markus Schiltknecht wrote:
In Postgres-R, I mostly use the terms 'local' and 'remote'.
Note that those terms only make sense if you limit yourself to
thinking the master is pushing dat
On 1/26/2007 4:40 PM, Jim Nasby wrote:
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 expo
On 1/26/2007 4:39 PM, Jim Nasby wrote:
On Jan 26, 2007, at 5:13 AM, Markus Schiltknecht wrote:
In Postgres-R, I mostly use the terms 'local' and 'remote'.
Note that those terms only make sense if you limit yourself to
thinking the master is pushing data out to the slave...
I think it'd mak
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
On Jan 26, 2007, at 5:13 AM, Markus Schiltknecht wrote:
In Postgres-R, I mostly use the terms 'local' and 'remote'.
Note that those terms only make sense if you limit yourself to
thinking the master is pushing data out to the slave...
I think it'd make the most sense if the name reflected w
[EMAIL PROTECTED] (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
>>
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 a
On 1/25/2007 7:33 PM, Tom Lane wrote:
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 th
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, "
On 1/25/2007 6:55 PM, Tom Lane wrote:
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 superuse
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 sessio
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
reg
21 matches
Mail list logo
