Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tfmlz-0053Wp-3K for pgsql-general@arkaria.postgresql.org; Wed, 05 Feb 2025 21:17:27 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1tfmlx-001Dax-R7 for pgsql-general@arkaria.postgresql.org; Wed, 05 Feb 2025 21:17:25 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tfmlx-001Dap-9u for pgsql-general@lists.postgresql.org; Wed, 05 Feb 2025 21:17:25 +0000 Received: from mail-oa1-x2b.google.com ([2001:4860:4864:20::2b]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1tfmlv-003Nnf-0K for pgsql-general@lists.postgresql.org; Wed, 05 Feb 2025 21:17:24 +0000 Received: by mail-oa1-x2b.google.com with SMTP id 586e51a60fabf-2b199bb8af9so752578fac.1 for ; Wed, 05 Feb 2025 13:17:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1738790242; x=1739395042; darn=lists.postgresql.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=UBHeXfaxX85XmP8trrz1rlNmu5ffDgOpAzOUrNP19dw=; b=Z8GY3rOgaTkkDvXPuGatLJhfhF78YyKYio5BZ92ZBdnOgWXv76JEuuSPf1MbcJtbar s0vFElVmmLiELr0DA/hV0FsMaw4HTsL31s8tfanGlzJyiVcQeJM2fDoLBZnigX3XrgFo 4cog7F3iH7PnuPE7/eIdWUqNqB4hEFvAz7tNeJeW2Db84z2Gs8jXaidbmt2fkwdED1Sw aoiZyODVIK7Fbxa3eb16WdvsTmWsscmFCwAuAdml2VPBEtAZnIQZYMUZOEXS+MpW2frA l3laC/0bO3ai0ZJgPKhEKwrh+k/pWYZCcUiDb620bpW6wKal3iq7vVnUlzlUvHbw1AOp 1JUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738790242; x=1739395042; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=UBHeXfaxX85XmP8trrz1rlNmu5ffDgOpAzOUrNP19dw=; b=FMLU6bC1UgSc2CTFIP3chrGiwXSI2m0EOks2+/ElxNe4lkWpOUqDaFYEG2v7aNBi00 zfSwqkUDhXkNuKdxSLShGfgWnnU79/uVwNYU4Tk9oIQVJ7pN+HyK6VM2UbQ9fgR4iuRd A0UT3rxfZbZEczhLm/NKINSljMuXYS178seLOUHuBHuSUlIUeYrXB0n7PNrVsXWz6HRY 6r2vUjtr+GCkQqXQ1ciiDFy3uz0FDDZz5uGQS6DQvRjsb3w6nFu73K0eNPQKrSN+hk3M VTEqx+uNNQgc0M87LQSdJ2zu7U0f0sq6tuS3weQ4nKHQCr0Cd7zLaDkl4CdR5S3Fi+Uf L9lQ== X-Gm-Message-State: AOJu0YxHLuj0p0mHpBVoilHqKfLMU64MRaSCWPb3/N1PLG07YMVWA980 JvkoR7Xuhn057UpYW9OJfsdITiN3fipD2vC+jAVNctoGeGVaxjescmt389Ao+ptua3pYPih3EG9 mDi3dJYqewIrYNtIpAzjtb8e33DWK0Q== X-Gm-Gg: ASbGnctFwJjJDrxb+1l7rI3Z11vq5htY9RGXA4AexVR3J4j0x+V1sDXoeMALehO4Jh0 zwKP7ygNJOyyHqW8kYpZExfWA4XBH1tN9HTPqs6ggCdK71NTCq8tY9YiCdDJjQCVBZD5pal6Wxj pVtrP3nkfyqnuFYPBEFooLlQ0bOz4SRNA= X-Google-Smtp-Source: AGHT+IGATzGMF5IvdoPXjF4wrZh0+IXOpkA9fiIy0WGO/ElS4cUvg50AJXYFB4IBfR8yta81UO9BdZ+8ePHjgdjRphM= X-Received: by 2002:a05:6871:209:b0:29e:2a06:8405 with SMTP id 586e51a60fabf-2b81edc215emr582730fac.19.1738790242354; Wed, 05 Feb 2025 13:17:22 -0800 (PST) MIME-Version: 1.0 References: <0057c073-6dcb-4425-92fc-3a766a78ee96@aklaver.com> In-Reply-To: From: Ron Johnson Date: Wed, 5 Feb 2025 16:17:11 -0500 X-Gm-Features: AWEUYZkP-aROPDNC6QeuqnEsST3A3fFcFqvL5V2SlHkS4RhoyysZjfJ4n-D00A0 Message-ID: Subject: Re: Table copy To: "pgsql-generallists.postgresql.org" Content-Type: multipart/alternative; boundary="000000000000bc0c64062d6ba637" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000bc0c64062d6ba637 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Could there have been a network hiccup? Or some sort of timeout? If I needed to transfer 360GB of data, I'd probably do something old school like: 1. write a PowerShell script to export a set of rows into a csv file, 7zip compress it, then rsync or scp it to the target. 2. Write a bash script to decompress it then load the data into the PG table. 3. Repeat (1) with the next set of data, and (2) until complete. Start the second (1) while the first (2) is running. That's how I migrated 12GB of Oracle data to PG (except of course bash, not PowerShell). On Wed, Feb 5, 2025 at 4:05=E2=80=AFPM Andy Hartman wrote: > nothing in log from mssql side and no anti-virus > > On Wed, Feb 5, 2025 at 2:06=E2=80=AFPM Adrian Klaver > wrote: > >> >> >> On 2/5/25 9:46 AM, Andy Hartman wrote: >> > [6992] ERROR: unexpected EOF on client connection with an open >> transaction >> > 2025-02-05 12:19:44.919 EST [6992] CONTEXT: COPY sqlt_data_1_2022_03, >> > line 24431524, column dataintegrity >> > 2025-02-05 12:19:44.919 EST [6992] STATEMENT: COPY sqlt_data_1_2022_0= 3 >> > (tagid, intvalue, floatvalue, stringvalue, datevalue, dataintegrity, >> > t_stamp) FROM STDIN (FORMAT BINARY) >> > 2025-02-05 12:19:44.919 EST [6992] FATAL: terminating connection >> > because protocol synchronization was lost >> >> You need to look at the other end of the connection also, in other words >> what is happening on the MS SQL Server 2016/Windows Server 2019 side? >> >> Also is there anti-virus software running on either end? >> >> >> >> -- >> Adrian Klaver >> adrian.klaver@aklaver.com >> > --=20 Death to , and butter sauce. Don't boil me, I'm still alive. lobster! --000000000000bc0c64062d6ba637 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Could there have been a ne= twork hiccup?=C2=A0 Or some sort of timeout?

If I = needed to transfer 360GB of data, I'd probably do something old school = like:

1. write a PowerShell script to export a set= of rows into a csv file, 7zip compress it, then rsync or scp it to the tar= get.
2. Write a bash script to decompress it then load the data i= nto the PG table.
3. Repeat (1) with the next set of data, and (2= ) until complete.=C2=A0 Start the second (1) while the first (2) is running= .

That's how I migrated 12GB of Oracle data to= PG (except of course bash, not PowerShell).

On Wed, Feb 5, 2025 at 4:05=E2=80=AFPM Andy Hartman <= hartman60home@gmail.com> = wrote:
nothi= ng in log from mssql side and no=C2=A0=C2=A0anti-virus=C2=A0
On Wed, F= eb 5, 2025 at 2:06=E2=80=AFPM Adrian Klaver <adrian.klaver@aklaver.com> wrote= :


On 2/5/25 9:46 AM, Andy Hartman wrote:
> [6992] ERROR:=C2=A0 unexpected EOF on client connection with an open t= ransaction
> 2025-02-05 12:19:44.919 EST [6992] CONTEXT:=C2=A0 COPY sqlt_data_1_202= 2_03,
> line 24431524, column dataintegrity
> 2025-02-05 12:19:44.919 EST [6992] STATEMENT:=C2=A0 COPY sqlt_data_1_2= 022_03
> (tagid, intvalue, floatvalue, stringvalue, datevalue, dataintegrity, <= br> > t_stamp) FROM STDIN (FORMAT BINARY)
> 2025-02-05 12:19:44.919 EST [6992] FATAL:=C2=A0 terminating connection=
> because protocol synchronization was lost

You need to look at the other end of the connection also, in other words what is happening on the MS SQL Server 2016/Windows Server 2019 side?

Also is there anti-virus software running on either end?



--
Adrian Klaver
adrian.klave= r@aklaver.com


--
Death to <Redacted>, and butter sauce.Don't boil me, I'm still alive.
<Redacted> lobs= ter!
--000000000000bc0c64062d6ba637--