Skip site navigation (1) Skip section navigation (2)

Re: Execute and PortalSuspended needs explicit transaction

From: "Francisco Figueiredo Jr(dot)" <fxjrlists(at)yahoo(dot)com(dot)br>
To: Oliver Jowett <oliver(at)opencloud(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Execute and PortalSuspended needs explicit transaction
Date: 2005-03-03 00:50:22
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Oliver Jowett wrote:
> Francisco Figueiredo Jr. wrote:
>> After some testing, I could send an Execute message with 2 as the manx
>> number of rows. After the second execute I get the following:
>> portal "" does not exist
>> Severity: ERROR
>> Code: 34000
>> I noticed that I could only get it working if I explicitly create a
>> transaction.
>> I thought it could be some Sync() messages I was sending after the first
>> execute, but when I removed them, I still get the problems.
> If you're sending any Sync messages at all between the two Executes, it 
> will indeed cause problems as Sync causes any implicitly-opened 
> transaction to be closed, which will in turn invalidate any non-holdable 
> portals.
> Do you have a trace of all the messages sent?
> -O

Hi Oliver.

Sorry for late response.

I have this sequence of calls from my client app:



Execute passing 2 as max rows.

And later a second Execute passing 2 as max rows.

Is there some flag or opt I can pass to postmaster so that it could log 
the messages received?

On this second execute I get the error I told you. If I use an explicit 
transaction, it works.

Thanks in advance.


Francisco Figueiredo Jr.
Membro Fundador do Projeto MonoBrasil - MonoBrasil Project Founder Member

"Science without religion is lame;
religion without science is blind."

                   ~ Albert Einstein

In response to

pgsql-hackers by date

Next:From: Qu TianlianDate: 2005-03-03 01:23:05
Subject: hi all
Previous:From: Bruce MomjianDate: 2005-03-03 00:03:02
Subject: Re: [pgsql-hackers-win32] snprintf causes regression tests

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group