public inbox for [email protected]help / color / mirror / Atom feed
[PATCH v15 03/14] meson: prereq: De-special-case pgevent's rc file handling 7+ messages / 3 participants [nested] [flat]
* [PATCH v15 03/14] meson: prereq: De-special-case pgevent's rc file handling @ 2022-09-13 17:07 Andres Freund <[email protected]> 0 siblings, 0 replies; 7+ messages in thread From: Andres Freund @ 2022-09-13 17:07 UTC (permalink / raw) There's really no need to build win32ver.rc as part of building pgmsgevent.rc. --- src/bin/pgevent/Makefile | 5 +++-- src/bin/pgevent/pgmsgevent.rc | 2 -- src/tools/msvc/Mkvcbuild.pm | 1 - 3 files changed, 3 insertions(+), 5 deletions(-) diff --git a/src/bin/pgevent/Makefile b/src/bin/pgevent/Makefile index dea79d3f137..04d49711d8d 100644 --- a/src/bin/pgevent/Makefile +++ b/src/bin/pgevent/Makefile @@ -17,7 +17,8 @@ ifeq ($(PORTNAME), win32) OBJS = \ pgevent.o \ - pgmsgevent.o + pgmsgevent.o \ + $(WIN32RES) NAME=pgevent SHLIB_LINK = @@ -29,7 +30,7 @@ install: all install-lib include $(top_srcdir)/src/Makefile.shlib -pgmsgevent.o: pgmsgevent.rc win32ver.rc +pgmsgevent.o: pgmsgevent.rc $(WINDRES) $< -o $@ --include-dir=$(top_builddir)/src/include --include-dir=$(top_srcdir)/src/include --include-dir=$(srcdir) --include-dir=. clean distclean: clean-lib diff --git a/src/bin/pgevent/pgmsgevent.rc b/src/bin/pgevent/pgmsgevent.rc index e69862e882c..0885a897e6f 100644 --- a/src/bin/pgevent/pgmsgevent.rc +++ b/src/bin/pgevent/pgmsgevent.rc @@ -1,4 +1,2 @@ LANGUAGE 0x9,0x1 1 11 MSG00001.bin - -#include "win32ver.rc" diff --git a/src/tools/msvc/Mkvcbuild.pm b/src/tools/msvc/Mkvcbuild.pm index 098bc3f1b09..ddb4f25eb12 100644 --- a/src/tools/msvc/Mkvcbuild.pm +++ b/src/tools/msvc/Mkvcbuild.pm @@ -425,7 +425,6 @@ sub mkvcbuild $pgevent->AddFiles('src/bin/pgevent', 'pgevent.c', 'pgmsgevent.rc'); $pgevent->AddResourceFile('src/bin/pgevent', 'Eventlog message formatter', 'win32'); - $pgevent->RemoveFile('src/bin/pgevent/win32ver.rc'); $pgevent->UseDef('src/bin/pgevent/pgevent.def'); $pgevent->DisableLinkerWarnings('4104'); -- 2.37.3.542.gdd3f6c4cae --ayx3t42hstokjw3l Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="v15-0004-meson-prereq-win-remove-date-from-version-number.patch" ^ permalink raw reply [nested|flat] 7+ messages in thread
* [PATCH v13 11/20] meson: prereq: De-special-case pgevent's rc file handling @ 2022-09-13 17:07 Andres Freund <[email protected]> 0 siblings, 0 replies; 7+ messages in thread From: Andres Freund @ 2022-09-13 17:07 UTC (permalink / raw) There's really no need to build win32ver.rc as part of building pgmsgevent.rc. --- src/bin/pgevent/Makefile | 5 +++-- src/bin/pgevent/pgmsgevent.rc | 2 -- src/tools/msvc/Mkvcbuild.pm | 1 - 3 files changed, 3 insertions(+), 5 deletions(-) diff --git a/src/bin/pgevent/Makefile b/src/bin/pgevent/Makefile index dea79d3f137..04d49711d8d 100644 --- a/src/bin/pgevent/Makefile +++ b/src/bin/pgevent/Makefile @@ -17,7 +17,8 @@ ifeq ($(PORTNAME), win32) OBJS = \ pgevent.o \ - pgmsgevent.o + pgmsgevent.o \ + $(WIN32RES) NAME=pgevent SHLIB_LINK = @@ -29,7 +30,7 @@ install: all install-lib include $(top_srcdir)/src/Makefile.shlib -pgmsgevent.o: pgmsgevent.rc win32ver.rc +pgmsgevent.o: pgmsgevent.rc $(WINDRES) $< -o $@ --include-dir=$(top_builddir)/src/include --include-dir=$(top_srcdir)/src/include --include-dir=$(srcdir) --include-dir=. clean distclean: clean-lib diff --git a/src/bin/pgevent/pgmsgevent.rc b/src/bin/pgevent/pgmsgevent.rc index e69862e882c..0885a897e6f 100644 --- a/src/bin/pgevent/pgmsgevent.rc +++ b/src/bin/pgevent/pgmsgevent.rc @@ -1,4 +1,2 @@ LANGUAGE 0x9,0x1 1 11 MSG00001.bin - -#include "win32ver.rc" diff --git a/src/tools/msvc/Mkvcbuild.pm b/src/tools/msvc/Mkvcbuild.pm index 098bc3f1b09..ddb4f25eb12 100644 --- a/src/tools/msvc/Mkvcbuild.pm +++ b/src/tools/msvc/Mkvcbuild.pm @@ -425,7 +425,6 @@ sub mkvcbuild $pgevent->AddFiles('src/bin/pgevent', 'pgevent.c', 'pgmsgevent.rc'); $pgevent->AddResourceFile('src/bin/pgevent', 'Eventlog message formatter', 'win32'); - $pgevent->RemoveFile('src/bin/pgevent/win32ver.rc'); $pgevent->UseDef('src/bin/pgevent/pgevent.def'); $pgevent->DisableLinkerWarnings('4104'); -- 2.37.3.542.gdd3f6c4cae --4uoxke3bx6ymzqvl Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="v13-0012-meson-prereq-win-remove-date-from-version-number.patch" ^ permalink raw reply [nested|flat] 7+ messages in thread
* [PATCH v13 11/20] meson: prereq: De-special-case pgevent's rc file handling @ 2022-09-13 17:07 Andres Freund <[email protected]> 0 siblings, 0 replies; 7+ messages in thread From: Andres Freund @ 2022-09-13 17:07 UTC (permalink / raw) There's really no need to build win32ver.rc as part of building pgmsgevent.rc. --- src/bin/pgevent/Makefile | 5 +++-- src/bin/pgevent/pgmsgevent.rc | 2 -- src/tools/msvc/Mkvcbuild.pm | 1 - 3 files changed, 3 insertions(+), 5 deletions(-) diff --git a/src/bin/pgevent/Makefile b/src/bin/pgevent/Makefile index dea79d3f137..04d49711d8d 100644 --- a/src/bin/pgevent/Makefile +++ b/src/bin/pgevent/Makefile @@ -17,7 +17,8 @@ ifeq ($(PORTNAME), win32) OBJS = \ pgevent.o \ - pgmsgevent.o + pgmsgevent.o \ + $(WIN32RES) NAME=pgevent SHLIB_LINK = @@ -29,7 +30,7 @@ install: all install-lib include $(top_srcdir)/src/Makefile.shlib -pgmsgevent.o: pgmsgevent.rc win32ver.rc +pgmsgevent.o: pgmsgevent.rc $(WINDRES) $< -o $@ --include-dir=$(top_builddir)/src/include --include-dir=$(top_srcdir)/src/include --include-dir=$(srcdir) --include-dir=. clean distclean: clean-lib diff --git a/src/bin/pgevent/pgmsgevent.rc b/src/bin/pgevent/pgmsgevent.rc index e69862e882c..0885a897e6f 100644 --- a/src/bin/pgevent/pgmsgevent.rc +++ b/src/bin/pgevent/pgmsgevent.rc @@ -1,4 +1,2 @@ LANGUAGE 0x9,0x1 1 11 MSG00001.bin - -#include "win32ver.rc" diff --git a/src/tools/msvc/Mkvcbuild.pm b/src/tools/msvc/Mkvcbuild.pm index 098bc3f1b09..ddb4f25eb12 100644 --- a/src/tools/msvc/Mkvcbuild.pm +++ b/src/tools/msvc/Mkvcbuild.pm @@ -425,7 +425,6 @@ sub mkvcbuild $pgevent->AddFiles('src/bin/pgevent', 'pgevent.c', 'pgmsgevent.rc'); $pgevent->AddResourceFile('src/bin/pgevent', 'Eventlog message formatter', 'win32'); - $pgevent->RemoveFile('src/bin/pgevent/win32ver.rc'); $pgevent->UseDef('src/bin/pgevent/pgevent.def'); $pgevent->DisableLinkerWarnings('4104'); -- 2.37.3.542.gdd3f6c4cae --4uoxke3bx6ymzqvl Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="v13-0012-meson-prereq-win-remove-date-from-version-number.patch" ^ permalink raw reply [nested|flat] 7+ messages in thread
* Logical replication failed with SSL SYSCALL error @ 2023-04-15 21:10 shaurya jain <[email protected]> 2023-04-19 11:56 ` Re: Logical replication failed with SSL SYSCALL error shaurya jain <[email protected]> 0 siblings, 1 reply; 7+ messages in thread From: shaurya jain @ 2023-04-15 21:10 UTC (permalink / raw) To: [email protected] Hi Team, Postgres Version:- 13.8 Issue:- Logical replication failing with SSL SYSCALL error Priority:-High We are migrating our database through logical replications, and all of sudden below error pops up in the source and target logs which leads us to nowhere. *Logs from Source:-* LOG: could not send data to client: Connection reset by peer STATEMENT: COPY public.test TO STDOUT FATAL: connection to client lost STATEMENT: COPY public.test TO STDOUT *Logs from Target:-* 2023-04-15 19:07:02 UTC::@:[1250]:ERROR: could not receive data from WAL stream: SSL SYSCALL error: Connection timed out 2023-04-15 19:07:02 UTC::@:[1250]:CONTEXT: COPY test, line 365326932 2023-04-15 19:07:03 UTC::@:[505]:LOG: background worker "logical replication worker" (PID 1250) exited with exit code 1 2023-04-15 19:07:03 UTC::@:[7155]:LOG: logical replication table synchronization worker for subscription " sub_tables_2_180", table "test" has started 2023-04-15 19:12:05 UTC:10.144.19.34(33276):postgres@webadmit_staging:[7112]:WARNING: there is no transaction in progress 2023-04-15 19:14:08 UTC:10.144.19.34(33324):postgres@webadmit_staging:[6052]:LOG: could not receive data from client: Connection reset by peer 2023-04-15 19:17:23 UTC::@:[2112]:ERROR: could not receive data from WAL stream: SSL SYSCALL error: Connection timed out 2023-04-15 19:17:23 UTC::@:[1089]:ERROR: could not receive data from WAL stream: SSL SYSCALL error: Connection timed out 2023-04-15 19:17:23 UTC::@:[2556]:ERROR: could not receive data from WAL stream: SSL SYSCALL error: Connection timed out 2023-04-15 19:17:23 UTC::@:[505]:LOG: background worker "logical replication worker" (PID 2556) exited with exit code 1 2023-04-15 19:17:23 UTC::@:[505]:LOG: background worker "logical replication worker" (PID 2112) exited with exit code 1 2023-04-15 19:17:23 UTC::@:[505]:LOG: background worker "logical replication worker" (PID 1089) exited with exit code 1 2023-04-15 19:17:23 UTC::@:[7287]:LOG: logical replication apply worker for subscription "sub_tables_2_180" has started 2023-04-15 19:17:23 UTC::@:[7288]:LOG: logical replication apply worker for subscription "sub_tables_3_192" has started 2023-04-15 19:17:23 UTC::@:[7289]:LOG: logical replication apply worker for subscription "sub_tables_1_180" has started Just after this error, all other replication slots get disabled for some time and come back online along with COPY command with the new PID in pg_stat_activity. I have a few queries regarding this:- 1. The exact reason for disconnection (Few articles claim memory and few network) 2. Will it lead to data inconsistency? 3. Does this new PID COPY command again migrate the whole data of the test table once again? Please help we got stuck here. -- Thanks and Regards, Shaurya Jain email:- [email protected] *Mobile:- +91-8802809405* LinkedIn:- https://www.linkedin.com/in/shaurya-jain-74353023 ^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: Logical replication failed with SSL SYSCALL error 2023-04-15 21:10 Logical replication failed with SSL SYSCALL error shaurya jain <[email protected]> @ 2023-04-19 11:56 ` shaurya jain <[email protected]> 2023-04-20 06:19 ` Re: Logical replication failed with SSL SYSCALL error vignesh C <[email protected]> 0 siblings, 1 reply; 7+ messages in thread From: shaurya jain @ 2023-04-19 11:56 UTC (permalink / raw) To: [email protected] Hi Team, Could you please help me with this, It's urgent for the production environment. On Wed, Apr 19, 2023 at 3:44 PM shaurya jain <[email protected]> wrote: > Hi Team, > > Could you please help, It's urgent for the production env? > > On Sun, Apr 16, 2023 at 2:40 AM shaurya jain <[email protected]> > wrote: > >> Hi Team, >> >> Postgres Version:- 13.8 >> Issue:- Logical replication failing with SSL SYSCALL error >> Priority:-High >> >> We are migrating our database through logical replications, and all of >> sudden below error pops up in the source and target logs which leads us to >> nowhere. >> >> *Logs from Source:-* >> LOG: could not send data to client: Connection reset by peer >> STATEMENT: COPY public.test TO STDOUT >> FATAL: connection to client lost >> STATEMENT: COPY public.test TO STDOUT >> >> *Logs from Target:-* >> 2023-04-15 19:07:02 UTC::@:[1250]:ERROR: could not receive data from WAL >> stream: SSL SYSCALL error: Connection timed out >> 2023-04-15 19:07:02 UTC::@:[1250]:CONTEXT: COPY test, line 365326932 >> 2023-04-15 19:07:03 UTC::@:[505]:LOG: background worker "logical >> replication worker" (PID 1250) exited with exit code 1 >> 2023-04-15 19:07:03 UTC::@:[7155]:LOG: logical replication table >> synchronization worker for subscription " sub_tables_2_180", table "test" >> has started >> 2023-04-15 19:12:05 UTC:10.144.19.34(33276):postgres@webadmit_staging:[7112]:WARNING: >> there is no transaction in progress >> 2023-04-15 19:14:08 UTC:10.144.19.34(33324):postgres@webadmit_staging:[6052]:LOG: >> could not receive data from client: Connection reset by peer >> 2023-04-15 19:17:23 UTC::@:[2112]:ERROR: could not receive data from WAL >> stream: SSL SYSCALL error: Connection timed out >> 2023-04-15 19:17:23 UTC::@:[1089]:ERROR: could not receive data from WAL >> stream: SSL SYSCALL error: Connection timed out >> 2023-04-15 19:17:23 UTC::@:[2556]:ERROR: could not receive data from WAL >> stream: SSL SYSCALL error: Connection timed out >> 2023-04-15 19:17:23 UTC::@:[505]:LOG: background worker "logical >> replication worker" (PID 2556) exited with exit code 1 >> 2023-04-15 19:17:23 UTC::@:[505]:LOG: background worker "logical >> replication worker" (PID 2112) exited with exit code 1 >> 2023-04-15 19:17:23 UTC::@:[505]:LOG: background worker "logical >> replication worker" (PID 1089) exited with exit code 1 >> 2023-04-15 19:17:23 UTC::@:[7287]:LOG: logical replication apply worker >> for subscription "sub_tables_2_180" has started >> 2023-04-15 19:17:23 UTC::@:[7288]:LOG: logical replication apply worker >> for subscription "sub_tables_3_192" has started >> 2023-04-15 19:17:23 UTC::@:[7289]:LOG: logical replication apply worker >> for subscription "sub_tables_1_180" has started >> >> Just after this error, all other replication slots get disabled for some >> time and come back online along with COPY command with the new PID in >> pg_stat_activity. >> >> I have a few queries regarding this:- >> >> 1. The exact reason for disconnection (Few articles claim memory and >> few network) >> 2. Will it lead to data inconsistency? >> 3. Does this new PID COPY command again migrate the whole data of the >> test table once again? >> >> Please help we got stuck here. >> -- >> Thanks and Regards, >> Shaurya Jain >> email:- [email protected] >> *Mobile:- +91-8802809405* >> LinkedIn:- https://www.linkedin.com/in/shaurya-jain-74353023 >> >> > > -- > Thanks and Regards, > Shaurya Jain > email:- [email protected] > *Mobile:- +91-8802809405* > LinkedIn:- https://www.linkedin.com/in/shaurya-jain-74353023 > > -- Thanks and Regards, Shaurya Jain email:- [email protected] *Mobile:- +91-8802809405* LinkedIn:- https://www.linkedin.com/in/shaurya-jain-74353023 ^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: Logical replication failed with SSL SYSCALL error 2023-04-15 21:10 Logical replication failed with SSL SYSCALL error shaurya jain <[email protected]> 2023-04-19 11:56 ` Re: Logical replication failed with SSL SYSCALL error shaurya jain <[email protected]> @ 2023-04-20 06:19 ` vignesh C <[email protected]> 2023-04-24 02:59 ` Re: Logical replication failed with SSL SYSCALL error shaurya jain <[email protected]> 0 siblings, 1 reply; 7+ messages in thread From: vignesh C @ 2023-04-20 06:19 UTC (permalink / raw) To: shaurya jain <[email protected]>; +Cc: [email protected] On Wed, 19 Apr 2023 at 17:26, shaurya jain <[email protected]> wrote: > > Hi Team, > > Could you please help me with this, It's urgent for the production environment. > > On Wed, Apr 19, 2023 at 3:44 PM shaurya jain <[email protected]> wrote: >> >> Hi Team, >> >> Could you please help, It's urgent for the production env? >> >> On Sun, Apr 16, 2023 at 2:40 AM shaurya jain <[email protected]> wrote: >>> >>> Hi Team, >>> >>> Postgres Version:- 13.8 >>> Issue:- Logical replication failing with SSL SYSCALL error >>> Priority:-High >>> >>> We are migrating our database through logical replications, and all of sudden below error pops up in the source and target logs which leads us to nowhere. >>> >>> Logs from Source:- >>> LOG: could not send data to client: Connection reset by peer >>> STATEMENT: COPY public.test TO STDOUT >>> FATAL: connection to client lost >>> STATEMENT: COPY public.test TO STDOUT >>> >>> Logs from Target:- >>> 2023-04-15 19:07:02 UTC::@:[1250]:ERROR: could not receive data from WAL stream: SSL SYSCALL error: Connection timed out >>> 2023-04-15 19:07:02 UTC::@:[1250]:CONTEXT: COPY test, line 365326932 >>> 2023-04-15 19:07:03 UTC::@:[505]:LOG: background worker "logical replication worker" (PID 1250) exited with exit code 1 >>> 2023-04-15 19:07:03 UTC::@:[7155]:LOG: logical replication table synchronization worker for subscription " sub_tables_2_180", table "test" has started >>> 2023-04-15 19:12:05 UTC:10.144.19.34(33276):postgres@webadmit_staging:[7112]:WARNING: there is no transaction in progress >>> 2023-04-15 19:14:08 UTC:10.144.19.34(33324):postgres@webadmit_staging:[6052]:LOG: could not receive data from client: Connection reset by peer >>> 2023-04-15 19:17:23 UTC::@:[2112]:ERROR: could not receive data from WAL stream: SSL SYSCALL error: Connection timed out >>> 2023-04-15 19:17:23 UTC::@:[1089]:ERROR: could not receive data from WAL stream: SSL SYSCALL error: Connection timed out >>> 2023-04-15 19:17:23 UTC::@:[2556]:ERROR: could not receive data from WAL stream: SSL SYSCALL error: Connection timed out >>> 2023-04-15 19:17:23 UTC::@:[505]:LOG: background worker "logical replication worker" (PID 2556) exited with exit code 1 >>> 2023-04-15 19:17:23 UTC::@:[505]:LOG: background worker "logical replication worker" (PID 2112) exited with exit code 1 >>> 2023-04-15 19:17:23 UTC::@:[505]:LOG: background worker "logical replication worker" (PID 1089) exited with exit code 1 >>> 2023-04-15 19:17:23 UTC::@:[7287]:LOG: logical replication apply worker for subscription "sub_tables_2_180" has started >>> 2023-04-15 19:17:23 UTC::@:[7288]:LOG: logical replication apply worker for subscription "sub_tables_3_192" has started >>> 2023-04-15 19:17:23 UTC::@:[7289]:LOG: logical replication apply worker for subscription "sub_tables_1_180" has started >>> >>> Just after this error, all other replication slots get disabled for some time and come back online along with COPY command with the new PID in pg_stat_activity. >>> >>> I have a few queries regarding this:- >>> >>> The exact reason for disconnection (Few articles claim memory and few network) This might be because of network failure, did you notice any network instability, could you check the TCP settings. You could check the following configurations tcp_keepalives_idle, tcp_keepalives_interval and tcp_keepalives_count. This means it will connect the server based on tcp_keepalives_idle seconds specified , if the server does not respond in tcp_keepalives_interval seconds it'll try again, and will consider the connection gone after tcp_keepalives_count failures. >>> Will it lead to data inconsistency? It will not lead to inconsistency. In case of failure the failed transaction will be rolled back. >>> Does this new PID COPY command again migrate the whole data of the test table once again? Yes, it will migrate the whole table data again in case of failures. Regards, Vignesh ^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: Logical replication failed with SSL SYSCALL error 2023-04-15 21:10 Logical replication failed with SSL SYSCALL error shaurya jain <[email protected]> 2023-04-19 11:56 ` Re: Logical replication failed with SSL SYSCALL error shaurya jain <[email protected]> 2023-04-20 06:19 ` Re: Logical replication failed with SSL SYSCALL error vignesh C <[email protected]> @ 2023-04-24 02:59 ` shaurya jain <[email protected]> 0 siblings, 0 replies; 7+ messages in thread From: shaurya jain @ 2023-04-24 02:59 UTC (permalink / raw) To: vignesh C <[email protected]>; +Cc: [email protected] Hi Vignesh, That's really prompt and solves our problem. Thank you buddy. Please go through my inline comments:- On Thu, Apr 20, 2023 at 11:49 AM vignesh C <[email protected]> wrote: > On Wed, 19 Apr 2023 at 17:26, shaurya jain <[email protected]> wrote: > > > > Hi Team, > > > > Could you please help me with this, It's urgent for the production > environment. > > > > On Wed, Apr 19, 2023 at 3:44 PM shaurya jain <[email protected]> > wrote: > >> > >> Hi Team, > >> > >> Could you please help, It's urgent for the production env? > >> > >> On Sun, Apr 16, 2023 at 2:40 AM shaurya jain <[email protected]> > wrote: > >>> > >>> Hi Team, > >>> > >>> Postgres Version:- 13.8 > >>> Issue:- Logical replication failing with SSL SYSCALL error > >>> Priority:-High > >>> > >>> We are migrating our database through logical replications, and all of > sudden below error pops up in the source and target logs which leads us to > nowhere. > >>> > >>> Logs from Source:- > >>> LOG: could not send data to client: Connection reset by peer > >>> STATEMENT: COPY public.test TO STDOUT > >>> FATAL: connection to client lost > >>> STATEMENT: COPY public.test TO STDOUT > >>> > >>> Logs from Target:- > >>> 2023-04-15 19:07:02 UTC::@:[1250]:ERROR: could not receive data from > WAL stream: SSL SYSCALL error: Connection timed out > >>> 2023-04-15 19:07:02 UTC::@:[1250]:CONTEXT: COPY test, line 365326932 > >>> 2023-04-15 19:07:03 UTC::@:[505]:LOG: background worker "logical > replication worker" (PID 1250) exited with exit code 1 > >>> 2023-04-15 19:07:03 UTC::@:[7155]:LOG: logical replication table > synchronization worker for subscription " sub_tables_2_180", table "test" > has started > >>> 2023-04-15 19:12:05 UTC:10.144.19.34(33276):postgres@webadmit_staging:[7112]:WARNING: > there is no transaction in progress > >>> 2023-04-15 19:14:08 UTC:10.144.19.34(33324):postgres@webadmit_staging:[6052]:LOG: > could not receive data from client: Connection reset by peer > >>> 2023-04-15 19:17:23 UTC::@:[2112]:ERROR: could not receive data from > WAL stream: SSL SYSCALL error: Connection timed out > >>> 2023-04-15 19:17:23 UTC::@:[1089]:ERROR: could not receive data from > WAL stream: SSL SYSCALL error: Connection timed out > >>> 2023-04-15 19:17:23 UTC::@:[2556]:ERROR: could not receive data from > WAL stream: SSL SYSCALL error: Connection timed out > >>> 2023-04-15 19:17:23 UTC::@:[505]:LOG: background worker "logical > replication worker" (PID 2556) exited with exit code 1 > >>> 2023-04-15 19:17:23 UTC::@:[505]:LOG: background worker "logical > replication worker" (PID 2112) exited with exit code 1 > >>> 2023-04-15 19:17:23 UTC::@:[505]:LOG: background worker "logical > replication worker" (PID 1089) exited with exit code 1 > >>> 2023-04-15 19:17:23 UTC::@:[7287]:LOG: logical replication apply > worker for subscription "sub_tables_2_180" has started > >>> 2023-04-15 19:17:23 UTC::@:[7288]:LOG: logical replication apply > worker for subscription "sub_tables_3_192" has started > >>> 2023-04-15 19:17:23 UTC::@:[7289]:LOG: logical replication apply > worker for subscription "sub_tables_1_180" has started > >>> > >>> Just after this error, all other replication slots get disabled for > some time and come back online along with COPY command with the new PID in > pg_stat_activity. > >>> > >>> I have a few queries regarding this:- > >>> > >>> The exact reason for disconnection (Few articles claim memory and few > network) > This might be because of network failure, did you notice any network > instability, could you check the TCP settings. > You could check the following configurations tcp_keepalives_idle, > tcp_keepalives_interval and tcp_keepalives_count. > This means it will connect the server based on tcp_keepalives_idle > seconds specified , if the server does not respond in > tcp_keepalives_interval seconds it'll try again, and will consider the > connection gone after tcp_keepalives_count failures. ---Yes you were > correct, that ssue was related to network where VPN tunnel got restarted > because of some miss configuration at tunnel side. By fixing that it > stands resolved so far. These params were set to below values:- 1. keepalives_idle 60 2. keepalives_interval 100 3. keepalives_count 60 > >>> Will it lead to data inconsistency? > It will not lead to inconsistency. In case of failure the failed > transaction will be rolled back. Yes, Migration was up to the mark after > fixing network. > > >>> Does this new PID COPY command again migrate the whole data of the > test table once again? > Yes, it will migrate the whole table data again in case of failures. Yes, > I follow you on that. Is there any way to rsync instead of simple copy? > > Regards, > Vignesh > -- Thanks and Regards, Shaurya Jain email:- [email protected] *Mobile:- +91-8802809405* LinkedIn:- https://www.linkedin.com/in/shaurya-jain-74353023 ^ permalink raw reply [nested|flat] 7+ messages in thread
end of thread, other threads:[~2023-04-24 02:59 UTC | newest] Thread overview: 7+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2022-09-13 17:07 [PATCH v15 03/14] meson: prereq: De-special-case pgevent's rc file handling Andres Freund <[email protected]> 2022-09-13 17:07 [PATCH v13 11/20] meson: prereq: De-special-case pgevent's rc file handling Andres Freund <[email protected]> 2022-09-13 17:07 [PATCH v13 11/20] meson: prereq: De-special-case pgevent's rc file handling Andres Freund <[email protected]> 2023-04-15 21:10 Logical replication failed with SSL SYSCALL error shaurya jain <[email protected]> 2023-04-19 11:56 ` Re: Logical replication failed with SSL SYSCALL error shaurya jain <[email protected]> 2023-04-20 06:19 ` Re: Logical replication failed with SSL SYSCALL error vignesh C <[email protected]> 2023-04-24 02:59 ` Re: Logical replication failed with SSL SYSCALL error shaurya jain <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox