Thread: BEGIN-cascade blocks application

It's PostgreSQL 7.3.4 on hppa-hp-hpux10.20, compiled by GCC 2.8.1 

I'm having a ported monitoring application using the libpq interface. 
After running well for several hours it surprisingly stopped 
without any error condition. 
The application was blocked completely. 
After re-start it worked as expected. 
I've turned on statement logging to find out 
about the last one being processed. It was 
BEGIN;
WARNING:  BEGIN: already a transaction in progress

It was the last of a cascade of duplicate BEGINs, 
and the only reason I could see for the application being blocked 
was this cascade. I eliminated those duplicates and now the 
application runs without any stops. 

Was it my fault? 
From reading the manual I was not aware firing duplicate BEGINs 
(ok, there were probably several thousand, but not uncommitted) 
could have such an drastic effect. 


Regards, Christoph 

Christoph Haller <ch@rodos.fzk.de> writes:
> I've turned on statement logging to find out 
> about the last one being processed. It was 
> BEGIN;
> WARNING:  BEGIN: already a transaction in progress

> It was the last of a cascade of duplicate BEGINs, 
> and the only reason I could see for the application being blocked 
> was this cascade.

I don't think so.  An extra BEGIN is a complete no-op except for
issuing that warning message.

> I eliminated those duplicates and now the 
> application runs without any stops. 

You fixed a bug in your application logic, then.  Or maybe the bug is
still there but happened not to be triggered in your second test.

Just to check, I fired 100000 consecutive "BEGIN;"s at PG 7.3.6 on
HPUX 10.20, and didn't see any particular hiccup... and no, I don't
think this was affected by any bugfixes between 7.3.4 and 7.3.6 ...
        regards, tom lane