Обсуждение: [GENERAL] Perl script is killed by SIGPIPE
Dear All,
We have one perl script that is opening DB connection and performaing insert DB operation.When duplicate entry Comming in query,Postgres forecfully killing process itself and in Postgres log "unexpected EOF on client connection" error is Comming.
This issue is not Comming every time.
We have found child script is killed by signal 13 SIGPIPE. When duplicate key violates error occured, script is killed but not all time.
Thanks in advance.
Yogesh
On Mon, Sep 11, 2017 at 9:02 PM, Yogesh Sharma <yogeshraj95@gmail.com> wrote:
Dear All,We have one perl script that is opening DB connection and performaing insert DB operation.When duplicate entry Comming in query,Postgres forecfully killing process itself and in Postgres log "unexpected EOF on client connection" error is Comming.This issue is not Comming every time.We have found child script is killed by signal 13 SIGPIPE. When duplicate key violates error occured, script is killed but not all time.
I'm going to bet that the SIGPIPE is totally unrelated to having a duplicate key violation. You will need to provide much more detail of what you observe to figure this out.
Yogesh Sharma wrote: > We have found child script is killed by signal 13 SIGPIPE. When duplicate > key violates error occured, script is killed but not all time. "child script" and this kind of error suggests that a forked process inherits a database connection opened by a parent process. When the database handle goes out of scope, it might close the connection to the database, affecting the parent process too, since it's the same connection. If you're using DBI, it has a setting to avoid that issue: https://metacpan.org/pod/DBI#InactiveDestroy Aside from that, inherited connections can't be used simultaneously by parent and child process. In general, a child process should open and close its own connection. Best regards, -- Daniel Vérité PostgreSQL-powered mailer: http://www.manitou-mail.org Twitter: @DanielVerite -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
> Daniel Verite wrote: > > Yogesh Sharma wrote: > > > We have found child script is killed by signal 13 SIGPIPE. When > > duplicate key violates error occured, script is killed but not all time. > > "child script" and this kind of error suggests that a forked process inherits a database connection opened by a parentprocess. > > When the database handle goes out of scope, it might close the connection to the database, affecting the parent processtoo, since it's the same connection. > > If you're using DBI, it has a setting to avoid that issue: > https://metacpan.org/pod/DBI#InactiveDestroy > > Aside from that, inherited connections can't be used simultaneously by parent and child process. > In general, a child process should open and close its own connection. In addition to Daniel's advice, be sure you have a try/catch around your DB work. If you've never used something like that, check out Try::Tiny. Then in the catch, you can print $dbh->errstr() to see what's really going on. I think Daniel has it correct though that you may not have a valid $dbh, so this is an app error. HTH, Kevin -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Dear Daniel,
Yes , we are using DBI for connection.
Basically we observed that after dbh->do() return nothing if we are trying to insert duplicate entry.
But it is not occurred always.
It return exit 1 if try to insert duplicate entry into Db.
But sometime it return nothing and child script is killed.
On Tuesday, September 12, 2017, Daniel Verite <daniel@manitou-mail.org> wrote:
On Tuesday, September 12, 2017, Daniel Verite <daniel@manitou-mail.org> wrote:
Yogesh Sharma wrote:
> We have found child script is killed by signal 13 SIGPIPE. When duplicate
> key violates error occured, script is killed but not all time.
"child script" and this kind of error suggests that a forked process
inherits a database connection opened by a parent process.
When the database handle goes out of scope, it might
close the connection to the database, affecting the
parent process too, since it's the same connection.
If you're using DBI, it has a setting to avoid that issue:
https://metacpan.org/pod/DBI#InactiveDestroy
Aside from that, inherited connections can't be used
simultaneously by parent and child process.
In general, a child process should open and close
its own connection.
Best regards,
--
Daniel Vérité
PostgreSQL-powered mailer: http://www.manitou-mail.org
Twitter: @DanielVerite
On Wed, Sep 13, 2017 at 11:04 AM, Yogesh Sharma <yogeshraj95@gmail.com> wrote: > Dear Daniel, > Yes , we are using DBI for connection. > > Basically we observed that after dbh->do() return nothing if we are trying > to insert duplicate entry. > But it is not occurred always. > It return exit 1 if try to insert duplicate entry into Db. > But sometime it return nothing and child script is killed. > > On Tuesday, September 12, 2017, Daniel Verite <daniel@manitou-mail.org> > wrote: >> >> Yogesh Sharma wrote: >> >> > We have found child script is killed by signal 13 SIGPIPE. When >> > duplicate >> > key violates error occured, script is killed but not all time. >> >> "child script" and this kind of error suggests that a forked process >> inherits a database connection opened by a parent process. >> >> When the database handle goes out of scope, it might >> close the connection to the database, affecting the >> parent process too, since it's the same connection. >> >> If you're using DBI, it has a setting to avoid that issue: >> https://metacpan.org/pod/DBI#InactiveDestroy >> >> Aside from that, inherited connections can't be used >> simultaneously by parent and child process. >> In general, a child process should open and close >> its own connection. >> >> Best regards, >> -- >> Daniel Vérité >> PostgreSQL-powered mailer: http://www.manitou-mail.org >> Twitter: @DanielVerite Yes, running your code under try-catch might help you in diagnosing the issue. Example: #------ use TryCatch; try { $rs_foo->insert($href_zoo); } catch($error) { print "Error: $error \n"; }; #------ -- Regards, Tirveni Yadav www.udyansh.org www.bael.io What is this Universe ? From what it arises ? Into what does it go? In freedom it arises, In freedom it rests and into freedom it melts away. Upanishads. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general