On Fri, 2007-01-26 at 12:36 -0500, Andrew Sullivan wrote:
> On Fri, Jan 26, 2007 at 11:58:54AM -0500, Sven Willenberger wrote:
> > > How did you do this?
>
> > If you are asking what the actual ddl script contained, it goes as
> > follows:
>
> No, I was trying to make sure you hadn't performed DDL on any node
> without EXECUTE. I was trying to eliminate the possibility of oid
> conflict across nodes, which was the first thing that sprung to mind.
>
> Sounds like it's more subtle than that, though, and needs more
> digging.
>
> A
>
I am having trouble digging through the source code to find the sequence
of events that occur during the execute script command but from what I
can tell there are three things that happen:
1) the tables on the affected nodes (subscribed by set) are locked and
"unmarked" for replication
2) the DDL actions are performed on those tables in the set as specified
by the SET ID parameter and the sql script itself (and EXECUTE ONLY ON
if applicable).
3) After successfully performing the DDL, the tables are then again
marked for replication and unlocked.
The problem lies in steps 2 and 3. While Step one only occurs on the
nodes that belong to the specified set, steps 2 and 3 are attempted
across all the nodes in the replication schema. I have verified this yet
again with a different execute ddl script occuring on a table that is
part of a set with 2 member nodes. On the nodes not part of this set, I
saw the error message "no such table" (indicating that the ddl was
trying to be run on the nodes that didn't even have that table). After
manually adding the table, step 2 finished on the node (not part of the
specified set). The next error message was:
ERROR: Slony-I: alterTableForReplication(): Table "public"."some_table" is
already in altered state
CONTEXT: SQL statement "SELECT "_T2".alterTableForReplication( $1 )"
PL/pgSQL function "ddlscript_complete_int" line 11 at perform
This would indicate that the process of making the tables ready for
replication is also being done on the non-member nodes of the set.
I think the easiest way to replicate this would be to have 3 servers.
Have Table1 exist on Server A and Server B
Have Table2 exist on Server B and Server C
Create a set to replicate Table1 from A to B
Create a set to replicate Table2 from B to C
DDL alter table1 add firstname text
execute script (SET ID=1, Filename ='/path/to/above/statement', EVENT
NODE = Server A node).
Monitor Server C and see the ddl script attempt to modify the
nonexistent Table1.
Sven
_______________________________________________
Slony1-general mailing list
[email protected]
http://gborg.postgresql.org/mailman/listinfo/slony1-general
