Re: help with error message from perl Pg - Mailing list pgsql-general

From Geoffrey
Subject Re: help with error message from perl Pg
Date
Msg-id 44980423.7080109@3times25.net
Whole thread Raw
In response to Re: help with error message from perl Pg  (Martijn van Oosterhout <kleptog@svana.org>)
Responses Re: help with error message from perl Pg
Re: help with error message from perl Pg
List pgsql-general
Martijn van Oosterhout wrote:
> On Tue, Jun 20, 2006 at 09:33:13AM -0400, Geoffrey wrote:
>> We have an unusual problem with some perl code that is processing data
>> via DBD facility.  Basically, the code consists of various subroutines
>> that are identified in a hash.  The primary script then references the
>> subroutines through a &$prog(...) syntax.  What appears to happen is
>> that all subroutines will run just fine if they do not need to do any
>> deletes or updates to the database.  Any subroutine that does a delete
>> or update runs fine, but the subsequent routine fails with the following
>> error:
>>
>> prgcaphlg: FATAL:  invalid frontend message type 78
>
> Errors in the FE-BE protocol are usually caused by users trying to use
> the same connection from multiple threads simultaneously. libpq doesn't
> handle that and so ends up sending things out of order.
>
> Are you using threads?

Not intentionally.  I'm assuming I would have to specify a threaded
process explicitly.

> Also, the database connection, how is the handle passed around? Youre
> not closing it accedently somewhere?

We considered that and have verified that we are not closing it.  But,
the question came up, should we be passing it by reference or value?  We
are doing the following:

my $conn = Pg::connectdb ("dbname=$db port=$port");
.
.
my $retVal = &$prog($conn, @args);

Question is, should we be doing:

my $retVal = &$prog(\$conn, @args);


FYI, there's no expectation of changing $conn in anyway within the sub
routines.

--
Until later, Geoffrey

Any society that would give up a little liberty to gain a little
security will deserve neither and lose both.  - Benjamin Franklin

pgsql-general by date:

Previous
From: Sim Zacks
Date:
Subject: Re: join on next row
Next
From: Wes
Date:
Subject: Re: Adding foreign key constraints without integrity