Message-ID: <6c4d94fe1b8aa391ae63c3863193fec4b9c87e16.camel@cybertec.at>
Subject: Re: fetch all from "<unnamed portal 1>"
From: Laurenz Albe <laurenz.albe@cybertec.at>
To: Ganesh Korde <ganeshakorde@gmail.com>, Siraj G <tosiraj.g@gmail.com>
Cc: Pgsql-admin <pgsql-admin@lists.postgresql.org>
Date: Wed, 09 Sep 2026 08:14:02 +0200
In-Reply-To: 
 <CAPNyb0Uih2BR1fWXCKGjeREvys2qG_ZL7EDk+Q96LKTLmFxywg@mail.gmail.com>
References: 
	<CAC5iy630jOKqU0Qdj3F6Z4jMyVoA-uKzkES7jgAm=b0maPj2gg@mail.gmail.com>
	 <CAPNyb0Uih2BR1fWXCKGjeREvys2qG_ZL7EDk+Q96LKTLmFxywg@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.60.2 (3.60.2-1.fc44) 
MIME-Version: 1.0
Archived-At: 
 <https://www.postgresql.org/message-id/6c4d94fe1b8aa391ae63c3863193fec4b9c87e16.camel%40cybertec.at>
Precedence: bulk

On Wed, 2026-09-09 at 10:42 +0530, Ganesh Korde wrote:
> On Wed, 9 Sept 2026, 10:01 am Siraj G, <tosiraj.g@gmail.com> wrote:
> > Postgres version 14 and the instance is a GCP cloud SQL.
> >=20
> > We have several application connections in ACTIVE state for several hou=
rs and the query text shows just fetch all from "<unnamed portal 1>".
> > What does it indicate? Could these sessions be in hung state?
>=20
> What do you see in wait events column in pg_stat_activity?

A good hint for debugging, but let me answer the question as it is:

Your application uses cursors to query the database.  A cursor is
first declared (that statement contains the query text), and then
you fetch the result rows from the cursor.

The query is taking a long time, but you don't get to see the query
text - that is only known to the executing session.

You should ask the people who wrote the application.

If that is not feasible, you could set

  log_min_duration_statement =3D 0
  log_line_prefix =3D '%m [%v] '

if you can afford to log all statements.

Then locate a slow FETCH statement in the log (you have to wait until
it completes) and find the preceding statements with the same virtual
transaction ID.  One of them will be the statement that declared the
cursor.

If you are more adventurous, you can break into one of the stalled backends
with a debugger and tickle out the statement.  That requires knowledge
of PostgreSQL's internals.

Yours,
Laurenz Albe