Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1x4HXy-00730B-2F for pgsql-admin@arkaria.postgresql.org; Wed, 09 Sep 2026 12:37:03 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1x4HXx-00Efjv-2L for pgsql-admin@arkaria.postgresql.org; Wed, 09 Sep 2026 12:37:01 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1x4HXw-00Efje-0x for pgsql-admin@lists.postgresql.org; Wed, 09 Sep 2026 12:37:01 +0000 Received: from sonic303-2.consmr.mail.bf2.yahoo.com ([74.6.131.41]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1x4HXt-00000003l6A-42Fg for pgsql-admin@lists.postgresql.org; Wed, 09 Sep 2026 12:36:59 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1788957415; bh=gVNS1oqf6IED74pRLS5siaGxgDDle2JEy2I8ytJ9z6Q=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From:Subject:Reply-To; b=hS7ZfNq3TXWDMHurUuXTkcJXR9Dpl5lpgtZLrPMfXzf6fsoOPUiZFIreDRs2KETWM0b1WA60mV1adbtkUp985AgwP8UcRWqI6HlmJp5vRLPLZkZ2t598ozkGWYizFKREKYXjcr1rlBsvwbazygXzI9EETJLnBt+oB6/gAo16njV72a2dc/Yayfxn5LlB4MKiBYBuncKotgLxbATdP/o37Ehec8ftgzt9eD7Xu6D9CqrYsOCN2VM9fjLt9DjKuTkMhWSfJVTn9fOz8jXGfvOcpOpLFTVJKShBoXkMfL7DMOnNOjZcuFujRq2dT2MXlyzabeanlxTTjL4bElwGtjK+ig== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1788957415; bh=fkhKXL6QHy5t2ag/dNcYEN2G2BNj9wEpLqAH9oTjZ8l=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=gEWcQiCKDM+cFKCDVZFtzh+ewYGObkhDLKCeMfdE6RRUYYCUClKKGnYNOezEw+SVmxLWXRZOivU+QWvZwQO2YiiEwr8t5fBdX6bQa53isOzYT19Tg5/2+kW0rs8E8GDw3bjrPjzcaW7kAdOocJEFP6DCLNTGTargs3ZmBWUy5h5AgZi5zkktohuSmHepKVkkXNNveR2KhFOqJ2sgumpU3Z6Q654f5ZqTVVH7CY63gnE0iy0pYJgu5i85inmDfg9jWS4Bl6uc9AnNiOzfcIWWtsDLHXyyWSM3OFg/2thOkC+OzegV2/Em56U98VsW18pL/nviJ/V1w7Q1hWCyZ0wh6w== X-YMail-OSG: AQSLKNUVM1nKBAS0rqDFqJ.1Y9uWqTrABJcIauCVPibufb_nSf1qaI2OXfYzENr eOElSgm6cp342q_B0O3UQYSF2pkt7v24VD_M_yGH_0SZ0ADFyCfHu4T2sEmwhOaHJ8426l8uzvbp IE1qDvn3jHPBrxIoz5b8n.PBOLvk1gZcDOfnsG2iyszY.bLWS_ZyVb4bgVR_3l4O.6Cs5B.5Ekex _ylJbRjx5XC_d8KnYk8o4KyhuVZwj6RLvnp.b.z8nw_10WfoNicW8N_.XtMXimdlkEDNENdRJTLk 2gKnTbDZV6_qSko0C8xR9feHyqkAWXK_a3yr3P1_OdyVIbDMIES1S54381H_H0lgRZMWWeqZZnFv htlcrAcjzGVzP8Ir.2hOyst_7SCU8Nbs2pasEODk5yx4gcSqOpNvjLrl5HYaZJ9Lm5_MCSqpqsjv RkzLaWV347GfjbjsU9IrN5VoeUGDdQFUyQVsedxulMzMzv_O0Jze3rCwvhBJjAy.a8geMHeUdBfx jJWNOXkJYqSRC4nokoxu4Ys3IhJcaXKINEr9lnUqJjiNqaAhr1BwyDnkZNUR.xoDmiHkNGqIMJaM YwND3gqVcTXApJ7uW4XZqdfP5bC2VRsIV71rl01f_q4dhaeQ0imy4y.HCL5eBRWz0NjsMyKyMu6a 5jwgG9YKJlrP1tSdEHp61TgIc5GAdJT7sMQrWB_dw_FC74lKPXfV4B2ZiJN61qT9oR76GvGDA3n0 UxoQjE7gXaRcUHg_Qhxw6EfrueqYo1SxG4asK6M1ezFTuXeVwMs2406oA3pGWzcZkLu.lEYlEtyP UfEtBU10XuOT6I8sGOWzGO6RfkO2tQHPKddybMuFbMqO9kkJLyFgu_H2Nw2YZC.kgmAC8fCQ_rUs sgR.fSODq0aVMUxihf7BMcirQWvLP0Q0w4cHsI1.wTlDooKy3VO9OSmRSqSvnfl2nx5wwkuxRtnd 8C8il9qrtVtNG3L5MDSSj6OQdiUfG33znBhMnX6tBycS0WjiCOq8oTSYJKvKk9uJpl.6O9OfWXPu zN2KcO9t.P.SWtsPN_oNmlllJBad1VFdUmnIdCvrZzLg.0dRQ27I7kSflVCzq7DwrhUMDrJ6nNYc iFtp7MQCeY_mnueO70R2eUz3CZPnRTUIoQEnkvuGDX.mm32PYTlCYCZIb4qVDblgXU3TQ1gTw60q Q1Qx29xTalYtjlig4srOv5hQ7fC0zdO5z2LYHwDRbM3ZSeMCMwOh3p4Ul.funFg..uSEHr2fVxgz J0LbfgmeB3Ywltbssxb3AEDA_z.YgY4HW6y2l.CZRwFUMsqy4icrATz88JjfzeKAzA_yy45Zsw5Q Ry8ZYcaQcU3V2zJ.poWHH3QUMuX3SIlfnoOE6h5k3S4qWRkYgKtNwpOhGkzQrLD0fMDAW1ca90ZA mwBHrvr111uINAKQXo.fq_af9zygk_87eZg2gZz8nVKgJnFZvNgolFXsXHdxyV_72wDCy8ojZrYR 17EDGbz86t3wRiho3uk424BsFUUf2CpNeFSz36oIpYnUggCx1BPq_zzgTzGxLsmsFMJ7GgKvJi6J lXaFNlKcTgCkdnSraffy_Xf98Re0o4ZY92jfUDukYtr8AKqgunV93JUDT9QP8nbwYhWxefalAnaE 4gAsXiGkc9x0G52J0fNFKoi557KxM9wjgsqeN0GQdaMZD1BJ5zYoZPGJCqWtZd7noaKbJ8TPGpqZ _E7v2i8Tj.CajhGXE5jAkpA2YGPKC8IM93fimAQPgECRdskWjmKa7MDQma.n1eBB6drBHX9tOAtH zcQF_EAJxF4TVaTo689gZnIEGk3T1diim9vG1We_j1jNYSwzkNcj0NA51PKBnf1w9h.MiG_lhGdb lgUF9feZzFdL1JouA28esB9iK0RX9BgvcjjTZhVUV1z00caawNJWwxc8eIKMYUHN2Pwh9p3pSWBE MuF540C3DU3ykaZp3tKXK7oMpKdZgrfbutzia.ffgHd0dNVW6hBQVDE_58mEOjL8Mud.m3ndBs5z o6YiOumtDmC2db4a.gjE1vzernfjrQkOILmLIH4XqLnsxKjuaLX0c3tMD4jdD6BJYf6ezd_J69zG a7Gilqhl6XvuLFdl.DoIhmk662Kvik7AIoAGCQxE3iO3Huy5U0rsvPJ7fD4G7bw5GtEp2oFTGFKX Ah68ZyXkvx6QS2.y8wZDJF7qFZib5.NSnW6Bf4Y2qAwOB8FQL7qKdOogfy8lUHmAS_medILT0Nfk OpaA65e19FRTVZNShKmZGbMyxhOfLjbeUvlfm1RAJNmomssKtA0i4nSkjm2n1VLGJHRZWYrqbXw6 VxgWhL6WseZyDbvfXB4IglFzxEW1MfsQKxXql X-Sonic-MF: X-Sonic-ID: 3d52e933-87cb-482a-8b22-3267e9d43e0e Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.bf2.yahoo.com with HTTP; Wed, 9 Sep 2026 12:36:55 +0000 Date: Wed, 9 Sep 2026 12:36:54 +0000 (UTC) From: Thomas Carroll To: Laurenz Albe , Siraj G Cc: Ganesh Korde , Pgsql-admin Message-ID: <900472209.835285.1788957414025@mail.yahoo.com> In-Reply-To: References: <6c4d94fe1b8aa391ae63c3863193fec4b9c87e16.camel@cybertec.at> Subject: Re: fetch all from "" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_835284_1368273249.1788957414024" X-Mailer: WebService/1.1.26460 YMailNorrin Content-Length: 7170 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk ------=_Part_835284_1368273249.1788957414024 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable In my experience, that query text indicates that a refcursor is in use - a= way for a function to return a large result set back to its caller. So whatever is processing those refcursors could be stepping through many r= ows.=C2=A0 Sounds like you have ruled out the possibility that the caller w= ent idle partway through processing those rows. TC On Wednesday, September 9, 2026 at 07:45:39 AM EDT, Siraj G wrote: =20 =20 wait events are just blank. I think I will try to figure out the minimal l= ogging to figure out the SQLs.Thank you! On Wed, Sep 9, 2026 at 11:44=E2=80=AFAM Laurenz Albe wrote: On Wed, 2026-09-09 at 10:42 +0530, Ganesh Korde wrote: > On Wed, 9 Sept 2026, 10:01 am Siraj G, 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 "". > > 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.=C2=A0 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 =C2=A0 log_min_duration_statement =3D 0 =C2=A0 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.=C2=A0 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.=C2=A0 That requires knowledge of PostgreSQL's internals. Yours, Laurenz Albe =20 ------=_Part_835284_1368273249.1788957414024 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In my experience, that query= text indicates that a refcursor is in use - a way for a function to return= a large result set back to its caller.

So whatever is = processing those refcursors could be stepping through many rows.  Soun= ds like you have ruled out the possibility that the caller went idle partwa= y through processing those rows.

TC

<= div dir=3D"ltr" data-setdir=3D"false">
=20
=20
On Wednesday, September 9, 2026 at 07:45:39 AM EDT,= Siraj G <tosiraj.g@gmail.com> wrote:


=20 =20
wait e= vents are just blank. I think I will try to figure out the minimal logging = to figure out the SQLs.
Thank you!

On Wed, Sep 9, 2026 at 11:44=E2= =80=AFAM Laurenz Albe <laurenz.albe@cybertec.at> wrote:
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.
> >
> > We have several application connections in ACTIVE state for sever= al hours and the query text shows just fetch all from "<unnamed portal 1= >".
> > What does it indicate? Could these sessions be in hung state?
>
> 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
------=_Part_835284_1368273249.1788957414024--