I've found that when setting up the schema (before the data dump),  
you'll need to split the schema dump into two halves.  Otherwise, when  
you go around to do the data dump, all the foreign keys are already  
there, and some of the COPY statements will fail because the foreign  
key needs to refer to a not-yet-existing row in another table.

I've taken up the habit of splitting my schema dump into 2 parts,  
right where the first "ALTER TABLE" statement shows up.

Hope this helps!

--Richard


On Jun 26, 2008, at 11:40 AM, Jennifer Spencer wrote:

> I too have had some issues with importing the slony1_dump.sh  
> results.  I think it has to do with the shell environment itself  
> interfering.  When I issued "set noglobs on", it sometimes improved  
> things. You could try that.  Or, you could try to remove those  
> special escape characters (maybe "{" is part of the problem).  Your  
> shell may be trying to interpret those characters on the way into  
> postgres.
>
> In my case, I had trouble with the way it handles NULL values.   
> Because I am impatient, I got sick of trying to figure out what was  
> going on in my particular shell.  Instead, I modified the program's  
> "copy out" command so that it handled null values as "NULL" instead  
> of the default "\N" (or was it "/N" - I can't remember).  You may  
> wish to actually edit a copy of slony1_dump, as I did, and change  
> the copy out command to something that will work, such as "copy  
> out ... with binary".
> See the postgres page : http://www.postgresql.org/docs/current/interactive/sql-copy.html
> for more info on your copy options.
>
> -Jennifer
>
> Andrew Sullivan wrote:
>> On Thu, Jun 26, 2008 at 01:13:43PM -0500, Troy Wolf wrote:
>>> I have not had a response to the error I received when trying to
>>> subscribe a third node to my set. So in the meantime, I'm
>> I didn't reply because I'm mystified.  It looked right to me.
>>> The import is failing, and it appears it is choking on an array
>>> column. That is, I have a table with a column that has a data type  
>>> of
>>> text[] -- which is an array. In the dump, this is represented as
>>> {a,b,c}. If I take the line that the import is choking on and remove
>>> that column, it works.
>>>
>>> Thoughts?
>> If you dump the table itself, what does that line say?  This also  
>> looks
>> right to me.
>> _______________________________________________
>> Slony1-general mailing list
>> Slony1-general at lists.slony.info
>> http://lists.slony.info/mailman/listinfo/slony1-general
> _______________________________________________
> Slony1-general mailing list
> Slony1-general at lists.slony.info
> http://lists.slony.info/mailman/listinfo/slony1-general