Perl script is killed by SIGPIPE

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 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.

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 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