On 12/22/2015 02:25 PM, CS DBA wrote:
> SLONY version 2.2.4
>
>

Does setting the client encoding for both connections (explicitly) to 
utf8 make any difference?

Are you able to determine what row/value is causing the problem?

What does the table look like? Just integers and text columns or 
anything more fancy or particularly large?

Are you able to restore a pg_dump of the database on 9.4 (to rule out 
there being some tightening of utf8 conversion in the newer version or 
something)




> On 12/22/2015 12:10 PM, Steve Singer wrote:
>> On 12/22/2015 02:03 PM, CS DBA wrote:
>>
>> You forgot to tell us your slony version
>>
>>> Hi All;
>>>
>>> We are replicating from a PostgreSQL 9.2 database (our Master) to a
>>> PostgreSQL 9.4 database (our slave) - server encoding is UTF8
>>>
>>> The slon process for the slave has this entry:
>>>
>>> 2015-12-22 11:28:31 CST ERROR  remoteWorkerThread_1: PQputCopyData() -
>>> server closed the connection unexpectedly
>>>       This probably means the server terminated abnormally
>>>       before or while processing the request.
>>> 2015-12-22 11:28:31 CST WARN   remoteWorkerThread_1: data copy for set 1
>>> failed 1 times - sleep 15 seconds
>>> FATAL:  invalid frontend message type 166
>>> 2015-12-22 11:28:31 CST ERROR  remoteWorkerThread_1: "rollback
>>> transaction" PGRES_FATAL_ERROR
>>> 2015-12-22 11:28:31 CST CONFIG slon: child terminated signal: 9; pid:
>>> 12450, current worker pid: 12450
>>> 2015-12-22 11:28:31 CST CONFIG slon: restart of worker in 10 seconds
>>>
>>> The process then begins to copy seemingly successful initial table
>>> sync's
>>> however the postgresql log file has entries like this:
>>>
>>>
>>> 2015-12-22 14:56:05 UTC /*[db name] [cluster name]*/ ERROR:  out of
>>> memory
>>> 2015-12-22 14:56:05 UTC /*[db name] [cluster name]*/ DETAIL: Cannot
>>> enlarge string buffer containing 0 bytes by 1572761385 more bytes.
>>> 2015-12-22 14:56:05 UTC /*[db name] [cluster name]*/ CONTEXT: COPY
>>> /*[table name] */, line 2332808
>>> 2015-12-22 14:56:05 UTC /*[db name] [cluster name]*/ STATEMENT: select
>>> "_/*[schema name]*/".prepareTableForCopy(11); copy "public"."/*[table
>>> name]*/" /*...*/  from stdin;
>>>
>>>
>>>
>>> 2015-12-22 14:56:05 UTC /*[db name] [cluster name]*/ LOG:  could not
>>> send data to client: Broken pipe
>>> 2015-12-22 14:56:05 UTC /*[db name] [cluster name]*/ FATAL: connection
>>> to client lost
>>> 2015-12-22 14:56:10 UTC /*[db name] [cluster name]*/ LOG:  could not
>>> send data to client: Broken pipe
>>> 2015-12-22 14:56:10 UTC /*[db name] [cluster name]*/ FATAL: connection
>>> to client lost
>>> 2015-12-22 17:28:50 UTC /*[db name] [cluster name]*/ ERROR: invalid
>>> byte sequence for encoding "UTF8": 0x9d
>>> 2015-12-22 17:28:50 UTC /*[db name] [cluster name]*/ CONTEXT: COPY
>>> transcript_indices, line 35227547
>>> 2015-12-22 17:28:50 UTC /*[db name] [cluster name]*/ STATEMENT: select
>>> "_/*[schema name]*/".prepareTableForCopy(7); copy "public"."/*[table
>>> name]*/" /*...*/ from stdin;
>>> 2015-12-22 17:28:54 UTC /*[db name] [cluster name]*/ FATAL: invalid
>>> frontend message type 166
>>>
>>>
>>>
>>> Thoughts?
>>>
>>> Thanks in advance...
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>