On Wed, 13 Aug 2003, David Wheeler wrote:

> On Wednesday, August 13, 2003, at 02:03  PM, Rudy Lippan wrote:
> 
> > What version of DBD::Pg are you using for this test? Version of 
> > mod_perl?
> 
> 1.30 from CVS a couple of weeks ago, but I've seen it with 1.22, too.
> 

So then it is nothing that I did ;)

> > Does this happen on every second request to httpd, or is it more
> > intermittent?
> 
> Intermittent.

But always on the second requst to the first process?

> > Have you tried DBI->trace()?  I would like to see a trace(9) for the 
> > hits
> > that cause the problem.
> 
> Will try it with your patch. See below.
> 
> On Wednesday, August 13, 2003, at 02:10  PM, Rudy Lippan wrote:
> 
> > here is a patch that gives some more info on what is going on in 
> > ping():
> 
> Applied, compiled, and installed. Attached are the results (with 
> DBI->trace(9), too). Note that it looks like begin is failing. What 
> might cause that to happen?
> 

It looks like something is happening to the Postgresql connection, which
is throwing off DBD::Pg and it gets into a weird state, so when it goes to 
excute "BEGIN" pg is throwing an error -- Does the BEGIN even make it to 
the databaes  server?  What do your pg server logs say?

I did not see any ping releated info in the log file. Did you re-enable 
the ping in _connect()?

What is the first process doing (Process #4627), Because I don't see it
executing any SQL statements other than flipping the state of Autocommit?  
I tried pulling a copy of Bric/Util/DBI.pm off of CVS on sourceforge but
the line numbers were not matching what was in the trace -- which version
should I be looking at?

Do you think that you might be able to put together a script that does not
require Bric -- it is a bit of a large hairy beast to install just to try
and duplicate the problem.



Something I noticed while looking at Bric::Util::DBI:

sub commit {
    return 1 unless TRANSACTIONAL;
    return 1 if $ENV{MOD_PERL} && !$_[0];
    _connect();                             #rl: <--- Back to autocommit.
    my $ret;
    eval { $ret = $dbh->commit };           #rl: <---- Roll back what? if 
                                            #rl: you needed to reconnect?
    throw_da(error => "Unable to commit transactions", payload => $@)
      if $@;
    eval { $ret = $dbh->{AutoCommit} = 1 };
    throw_da(error => "Unable to turn AutoCommit on", payload => $@)
      if $@;
    return $ret;
}

Another case is where the DB server is restarted after a begin():

$bric_dbh->begin();
### Database server is restarted. ###
$bric_dbh->prepare(); # You _connect() here and are back in autocommit mode

DO_STUF: {
  # everthing is automatically commited.
}
$bric_dbh->rollback() # does not do jack because you are in autocommit.


The above could could be what casues the commit ineffective in autocommit 
mode error messages.  My guess is that things were getting stuck in ping, 
when you hit stop you poped out of whatever was blocking (on a signal?) 
and then the next db call you made automatically reconnected to the db 
which caused some of the other error messages that you were seeing in the 
logs?


Rudy 





---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to