FYI, I got this figured out. Thanks to all who responded!

It turns out that the two tables I was having trouble with INHERIT from
other tables, and those base tables were also making it into my
replication set. I'm still not that familiar with this schema, and I
generated the set list with slony_setup.pl. So at subscription time the
child table was getting populated, then the base table was getting
deleted/copied AFTER the child table, but of course the records in the
child were lost. 

I don't know if the copy_set logic in remote_worker.c should do a
"delete only"? I don't know what other issues there might be with that
(or if it would even work for . At any rate, it's the user's
responsibility to know their schema!

Live and learn....

Thanks again.

- DAP

>-----Original Message-----
>From: Ed L. [mailto:pgsql at bluepolka.net] 
>Sent: Tuesday, November 09, 2004 5:43 PM
>To: David Parker; Jan Wieck
>Cc: slony1-general at gborg.postgresql.org
>Subject: Re: [Slony1-general] losing data on initial enable 
>subscribtion
>
>On Tuesday November 9 2004 3:33, David Parker wrote:
>> sigh...no, no triggers on the table that I can see, and I'm 
>%100 sure 
>> I'm not telling slonik to ignore any, but seems like it has to be 
>> something like that. Would a trigger firing show up in the 
>server log?
>
>Here's a shot in the dark:  I had an 8-hr copy set operation 
>that looked great for hours, but aborted when slon got 
>clobbered and rolled back all the copies.  I saw another slon 
>abort when it encountered what I guess was a conflict with 
>concurrent autovacs (simple_heap_update error).  I guess the 
>way to verify is to see the commit line for that pid in the 
>server log.  
>You've probably already grepped your slon and server logs for errors...
>
>Ed
>
>
>>
>> Thanks.
>>
>> - DAP
>>
>> >-----Original Message-----
>>
>> From: Jan Wieck [mailto:JanWieck at Yahoo.com]
>>
>> >Sent: Tuesday, November 09, 2004 5:02 PM
>> >To: David Parker
>> >Cc: Darcy Buskermolen; slony1-general at gborg.postgresql.org
>> >Subject: Re: [Slony1-general] losing data on initial enable 
>> >subscribtion
>> >
>> >On 11/9/2004 2:43 PM, David Parker wrote:
>> >> You mentioned that a similar problem was seen on HP, but
>> >
>> >that the problem seemed to go away. Do you recall if the tables 
>> >involved had constraints, as my problem table does? I'm probably 
>> >grasping at straws, but I can't find any other differences with the 
>> >other tables that are actually working OK.
>> >
>> >> Is there another level of debugging I can turn on in the
>> >
>> >server? If somehow a constraint cascade delete were firing, 
>would it 
>> >show up in the server log?
>> >
>> >
>> >As per the slon log, it actually shovels 218 bytes of data 
>from copy 
>> >to copy ... could it be that you have a trigger on that table which 
>> >is told to be ignored (store trigger) and that then suppresses the 
>> >actual insert by returning NULL?
>> >Grasping straws too ;-)
>> >
>> >
>> >Jan
>> >
>> >> Thanks.
>> >>
>> >> - DAP
>> >>
>> >>>-----Original Message-----
>> >>>From: David Parker
>> >>>Sent: Monday, November 08, 2004 7:17 PM
>> >>>To: 'Darcy Buskermolen'; slony1-general at gborg.postgresql.org
>> >>>Subject: RE: [Slony1-general] losing data on initial enable 
>> >>>subscribtion
>> >>>
>> >>>Sorry, I should have provided that info:
>> >>>
>> >>>Solaris 9/intel
>> >>>postgres 7.4.5
>> >>>slony 1.0.2
>> >>>
>> >>>same configuration on both sides.
>> >>>
>> >>>Thanks.
>> >>>
>> >>>- DAP
>> >>>
>> >>>>-----Original Message-----
>> >>>>From: slony1-general-bounces at gborg.postgresql.org
>> >>>>[mailto:slony1-general-bounces at gborg.postgresql.org] On
>> >>>
>> >>>Behalf Of Darcy
>> >>>
>> >>>>Buskermolen
>> >>>>Sent: Monday, November 08, 2004 6:49 PM
>> >>>>To: slony1-general at gborg.postgresql.org
>> >>>>Subject: Re: [Slony1-general] losing data on initial enable 
>> >>>>subscribtion
>> >>>>
>> >>>>On November 8, 2004 03:28 pm, David Parker wrote:
>> >>>>> I am having a problem where the initial copy of data into
>> >
>> >a "slave"
>> >
>> >>>>> table seems to be getting lost. I have a table called
>> >
>> >"schema", and
>> >
>> >>>>> our application database gets installed with 2 records in
>> >>>>
>> >>>>this table.
>> >>>>
>> >>>>> I see the copy happening in the log, but when I look at the 
>> >>>>> slave table after the subscription is done, it's empty.
>> >>>>>
>> >>>>> I have a couple of other pre-populated tables like this, but
>> >>>>
>> >>>>they are
>> >>>>
>> >>>>> not exhibiting the same behavior. The difference is that the
>> >>>>
>> >>>>"schema"
>> >>>>
>> >>>>> table has FK constraints pointing at it, and the other
>> >>>>
>> >>>>tables do not.
>> >>>>
>> >>>>> At the point when I am configuring replication, none of
>> >
>> >the tables
>> >
>> >>>>> with FKs pointing to "schema" table have any data in them,
>> >>>>
>> >>>>and I have
>> >>>>
>> >>>>> further verified that these constraints are defined "NO
>> >>>>
>> >>>>ACTION" on delete/update.
>> >>>>
>> >>>>> I have included what I think are the relevant portions of
>> >
>> >the slony
>> >
>> >>>>> log and the server log (-d 5). The server log shows the
>> >>>>
>> >>>>"analyze" done
>> >>>>
>> >>>>> by slon showing 2 records, which is what I expect to see.
>> >>>>
>> >>>>I've looked
>> >>>>
>> >>>>> elsewhere in the server log and don't see evidence (a 
>constraint 
>> >>>>> cascade or something) of a subsequent delete happening on
>> >
>> >the table.
>> >
>> >>>>> Any ideas for further places to look would be a great help.
>> >>>>
>> >>>>Some background information would be usefull namely:
>> >>>>Origin Database version
>> >>>>		OS version/distro
>> >>>>		Hardware type
>> >>>>		Slon Version
>> >>>>		Slony Schema version
>> >>>>
>> >>>>Subscriber Datablase version
>> >>>>		OS version/distro
>> >>>>		Hardware type
>> >>>>		Slon version
>> >>>>		Slony Schema version
>> >>>>
>> >>>>I ask this because there were reports of something simular
>> >
>> >to this on
>> >
>> >>>>HP's
>> >>>>Tru64 testdrive platform and when we went to debug it in 
>depth the 
>> >>>>errors went away.
>> >>>>
>> >>>>> slon log:
>> >>>>>
>> >>>>>==============================================================
>> >>>>
>> >>>>=========
>> >>>>
>> >>>>>==== ========================= DEBUG2 remoteWorkerThread_1:
>> >>>>
>> >>>>copy table
>> >>>>
>> >>>>>public.schema
>> >>>>> DEBUG3 remoteWorkerThread_1: table public.schema does not 
>> >>>>>require Slony-I  serial key DEBUG2 remoteWorkerThread_1: 218 
>> >>>>>bytes
>> >>>
>> >>>copied for
>> >>>
>> >>>>>table  public.schema DEBUG2 remoteWorkerThread_1: 0.471
>> >>>>
>> >>>>seconds to copy
>> >>>>
>> >>>>>table  public.schema
>> >>>>>==============================================================
>> >>>>
>> >>>>=========
>> >>>>
>> >>>>>====
>> >>>>>=========================
>> >>>>>
>> >>>>> server log:
>> >>>>>
>> >>>>>==============================================================
>> >>>>
>> >>>>=========
>> >>>>
>> >>>>>==== ========================= DEBUG:  StartTransactionCommand
>> >>>>> LOG:  statement: delete from public.schema; copy
>> >
>> >public.schema from
>> >
>> >>>>>stdin;
>> >>>>> DEBUG:  parse tree:
>> >>>>> DETAIL:  {QUERY :commandType 4 :querySource 0 :canSetTag true
>> >>>>>
>> >>>>>:utilityStmt  <>
>> >>>>>:
>> >>>>> 	:resultRelation 1 :into <> :hasAggs false :hasSubLinks
>> >>>>
>> >>>>false :rtable ({RTE
>> >>>>
>> >>>>> 	:alias <> :eref {ALIAS :aliasname schema :colnames
>> >>>>
>> >>>>("dbid" "tuid"
>> >>>>
>> >>>>> 	"foundryversion" "name" "description" "objecttype"
>> >>>>
>> >>>>"generic" "state"
>> >>>>
>> >>>>> "visible" "schematype" "namespace" "content")} :rtekind 0
>> >>>>>
>> >>>>:relid 17626
>> >>>>:
>> >>>>> :inh true
>> >>>>> :
>> >>>>> 	:inFromCl false :checkForRead false :checkForWrite true
>> >>>>:
>> >>>>:checkAsUser 0})
>> >>>>:
>> >>>>> 	:jointree {FROMEXPR :fromlist ({RANGETBLREF :rtindex
>> >>>>
>> >>>>1}) :quals <>}
>> >>>>
>> >>>>> 	: :rowMarks
>> >>>>>
>> >>>>> 	() :targetList <> :groupClause <> :havingQual <>
>> >>>>>
>> >>>>:distinctClause <>
>> >>>>:
>> >>>>> 	:sortClause <> :limitOffset <> :limitCount <> 
>:setOperations <>
>> >>>>> 	:resultRelations ()}
>> >>>>>
>> >>>>> DEBUG:  rewritten parse tree:
>> >>>>> DETAIL:  ({QUERY :commandType 4 :querySource 0 :canSetTag true
>> >>>>>
>> >>>>> :utilityStmt <>
>> >>>>> :
>> >>>>> 	:resultRelation 1 :into <> :hasAggs false :hasSubLinks
>> >>>>
>> >>>>false :rtable ({RTE
>> >>>>
>> >>>>> 	:alias <> :eref {ALIAS :aliasname schema :colnames
>> >>>>
>> >>>>("dbid" "tuid"
>> >>>>
>> >>>>> 	"foundryversion" "name" "description" "objecttype"
>> >>>>
>> >>>>"generic" "state"
>> >>>>
>> >>>>> "visible" "schematype" "namespace" "content")} :rtekind 0
>> >>>>>
>> >>>>:relid 17626
>> >>>>:
>> >>>>> :inh true
>> >>>>> :
>> >>>>> 	:inFromCl false :checkForRead false :checkForWrite true
>> >>>>:
>> >>>>:checkAsUser 0})
>> >>>>:
>> >>>>> 	:jointree {FROMEXPR :fromlist ({RANGETBLREF :rtindex
>> >>>>
>> >>>>1}) :quals <>}
>> >>>>
>> >>>>> 	: :rowMarks
>> >>>>>
>> >>>>> 	() :targetList <> :groupClause <> :havingQual <>
>> >>>>>
>> >>>>:distinctClause <>
>> >>>>:
>> >>>>> 	:sortClause <> :limitOffset <> :limitCount <> 
>:setOperations <>
>> >>>>> 	:resultRelations ()})
>> >>>>>
>> >>>>> DEBUG:  plan:
>> >>>>> DETAIL:  {SEQSCAN :startup_cost 0.00 :total_cost 1.02
>> >:
>> >:plan_rows 2
>> >:
>> >>>>> :plan_width 6
>> >>>>> :
>> >>>>> 	:targetlist ({TARGETENTRY :resdom {RESDOM :resno 1
>> >>>>:
>> >>>>:restype 27 :restypmod
>> >>>>:
>> >>>>> 	: -1 resname ctid :ressortgroupref 0 :resorigtbl 0
>> >>>>:
>> >>>>:resorigcol 0 :resjunk
>> >>>>:
>> >>>>> 	: true} expr {VAR :varno 1 :varattno -1 :vartype 27
>> >>>>:
>> >>>>:vartypmod -1
>> >>>>:
>> >>>>> 	: :varlevelsup 0 varnoold 1 :varoattno -1}}) :qual <>
>> >>>>:
>> >>>>:lefttree <>
>> >>>>:
>> >>>>> 	: :righttree <> :initPlan <> extParam () :allParam ()
>> >>>>:
>> >>>>:nParamExec 0
>> >>>>:
>> >>>>> 	: :scanrelid 1}
>> >>>>>
>> >>>>> DEBUG:  ProcessQuery
>> >>>>> DEBUG:  parse tree:
>> >>>>> DETAIL:  {QUERY :commandType 5 :querySource 0 :canSetTag true
>> >>>>>
>> >>>>> :utilityStmt ?
>> >>>>> :
>> >>>>> 	:resultRelation 0 :into <> :hasAggs false :hasSubLinks
>> >>>>
>> >>>>false :rtable <>
>> >>>>
>> >>>>> 	:jointree <> :rowMarks () :targetList <> :groupClause
>> >>>>
>> >>>><> :havingQual <>
>> >>>>
>> >>>>> 	:distinctClause <> :sortClause <> :limitOffset 
><> :limitCount <>
>> >>>>> 	:setOperations <> :resultRelations ()}
>> >>>>>
>> >>>>> DEBUG:  rewritten parse tree:
>> >>>>> DETAIL:  ({QUERY :commandType 5 :querySource 0 :canSetTag true
>> >>>>>
>> >>>>> :utilityStmt ?
>> >>>>> :
>> >>>>> 	:resultRelation 0 :into <> :hasAggs false :hasSubLinks
>> >>>>
>> >>>>false :rtable <>
>> >>>>
>> >>>>> 	:jointree <> :rowMarks () :targetList <> :groupClause
>> >>>>
>> >>>><> :havingQual <>
>> >>>>
>> >>>>> 	:distinctClause <> :sortClause <> :limitOffset 
><> :limitCount <>
>> >>>>> 	:setOperations <> :resultRelations ()})
>> >>>>>
>> >>>>> DEBUG:  ProcessUtility
>> >>>>> DEBUG:  find_in_dynamic_libpath: trying
>> >>>>
>> >>>>"/home/dparker/install/ed9i04/tazz/postgresql/lib/slony1_funcs"
>> >>>>
>> >>>> CONTEXT:
>> >>>>> COPY schema, line 1: "1
>> >>>>
>> >>>>THISISTHEMOTHEROFALLSCHEMASRIGHT	1.0	XSD	Fake
>> >>>>
>> >>>>> schema representing the xsd: schema	schema	f	\N
>> >>>>
>> >>>>t	\N..." DEBUG:
>> >>>>> find_in_dynamic_libpath: trying
>> >>>>> "/home/dparker/install/ed9i04/tazz/lib/slony1_funcs"
>> >>>>
>> >>>>CONTEXT:  COPY schema,
>> >>>>
>> >>>>> line 1: "1	THISISTHEMOTHEROFALLSCHEMASRIGHT	1.0
>> >>>>
>> >>>>XSD	Fake schema
>> >>>>
>> >>>>> representing the xsd: schema	schema	f	\N	t
>> >>>>
>> >>>>\N..." DEBUG:
>> >>>>> find_in_dynamic_libpath: trying
>> >>>>
>> >>>>"/home/dparker/install/ed9i04/tazz/postgresql/lib/slony1_funcs.
>> >>>>
>> >>>>so" CONTEXT:
>> >>>>>  COPY schema, line 1: "1
>> >>>>
>> >>>>THISISTHEMOTHEROFALLSCHEMASRIGHT	1.0	XSD	Fake
>> >>>>
>> >>>>> schema representing the xsd: schema	schema	f	\N
>> >>>>
>> >>>>t	\N..." DEBUG:
>> >>>>> CommitTransactionCommand
>> >>>>> DEBUG:  StartTransactionCommand
>> >>>>> LOG:  statement: analyze public.schema;
>> >>>>> DEBUG:  parse tree:
>> >>>>> DETAIL:  {QUERY :commandType 5 :querySource 0 :canSetTag true
>> >>>>>
>> >>>>> :utilityStmt ?
>> >>>>> :
>> >>>>> 	:resultRelation 0 :into <> :hasAggs false :hasSubLinks
>> >>>>
>> >>>>false :rtable <>
>> >>>>
>> >>>>> 	:jointree <> :rowMarks () :targetList <> :groupClause
>> >>>>
>> >>>><> :havingQual <>
>> >>>>
>> >>>>> 	:distinctClause <> :sortClause <> :limitOffset 
><> :limitCount <>
>> >>>>> 	:setOperations <> :resultRelations ()}
>> >>>>>
>> >>>>> DEBUG:  rewritten parse tree:
>> >>>>> DETAIL:  ({QUERY :commandType 5 :querySource 0 :canSetTag true
>> >>>>>
>> >>>>> :utilityStmt ?
>> >>>>> :
>> >>>>> 	:resultRelation 0 :into <> :hasAggs false :hasSubLinks
>> >>>>
>> >>>>false :rtable <>
>> >>>>
>> >>>>> 	:jointree <> :rowMarks () :targetList <> :groupClause
>> >>>>
>> >>>><> :havingQual <>
>> >>>>
>> >>>>> 	:distinctClause <> :sortClause <> :limitOffset 
><> :limitCount <>
>> >>>>> 	:setOperations <> :resultRelations ()})
>> >>>>>
>> >>>>> DEBUG:  ProcessUtility
>> >>>>> DEBUG:  analyzing "public.schema"
>> >>>>> DEBUG:  "schema": 1 pages, 2 rows sampled, 2 estimated total 
>> >>>>> rows
>> >>>>> DEBUG:  CommitTransactionCommand
>> >>>>>
>> >>>>>==============================================================
>> >>>>
>> >>>>=========
>> >>>>
>> >>>>>====
>> >>>>>=========================
>> >>>>>
>> >>>>>
>> >>>>> - DAP
>> >>>>
>> >>>>---------------------------------------------------------------
>> >>>>------------
>> >>>>
>> >>>>>------- David Parker    Tazz Networks    (401) 709-5130
>> >>>>>
>> >>>>> _______________________________________________
>> >>>>> Slony1-general mailing list
>> >>>>> Slony1-general at gborg.postgresql.org
>> >>>>> http://gborg.postgresql.org/mailman/listinfo/slony1-general
>> >>>>
>> >>>>--
>> >>>>Darcy Buskermolen
>> >>>>Wavefire Technologies Corp.
>> >>>>ph: 250.717.0200
>> >>>>fx:  250.763.1759
>> >>>>http://www.wavefire.com
>> >>>>_______________________________________________
>> >>>>Slony1-general mailing list
>> >>>>Slony1-general at gborg.postgresql.org
>> >>>>http://gborg.postgresql.org/mailman/listinfo/slony1-general
>> >>
>> >> _______________________________________________
>> >> Slony1-general mailing list
>> >> Slony1-general at gborg.postgresql.org
>> >> http://gborg.postgresql.org/mailman/listinfo/slony1-general
>> >
>> >--
>> >#==============================================================
>> >========#
>> ># It's easier to get forgiveness for being wrong than for being 
>> >right. # # Let's break this rule - forgive me.
>> >        #
>> >#==================================================
>> >JanWieck at Yahoo.com #
>>
>> _______________________________________________
>> Slony1-general mailing list
>> Slony1-general at gborg.postgresql.org
>> http://gborg.postgresql.org/mailman/listinfo/slony1-general
>
>