Feedback-ID: i0fe9450f:Fastmail
Date: Fri, 8 Sep 2023 11:48:28 +0900
From: Michael Paquier <michael@paquier.xyz>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: "James Pang (chaolpan)" <chaolpan@cisco.com>,
	PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Subject: Re: FW: query pg_stat_ssl hang 100%cpu
Message-ID: <ZPqLfAk8n/HrB6G4@paquier.xyz>
References: 
 <PH0PR11MB519185994AC536A50F27BFF0D6EEA@PH0PR11MB5191.namprd11.prod.outlook.com>
 <PH0PR11MB5191FAF4D1FF00F918018F5ED6EEA@PH0PR11MB5191.namprd11.prod.outlook.com>
 <CA+hUKGJ53Nghv5XdPKmOpmUb3zcYUF9DzBXB_S5Q030t6pBLiQ@mail.gmail.com>
 <PH0PR11MB51916128C1D23592AC86D535D6EEA@PH0PR11MB5191.namprd11.prod.outlook.com>
 <CA+hUKGJKXdMyLdqYDioVnAUiAE4GKdmxues61e+4nz5YHnmQkQ@mail.gmail.com>
 <PH0PR11MB519113BEF76A806183AADC78D6EEA@PH0PR11MB5191.namprd11.prod.outlook.com>
 <CA+hUKG+yZFvv+C1oxBFWiHNsay+uVN8LXTwFsntE5NTh4dwahQ@mail.gmail.com>
 <PH0PR11MB51917DE71E58A7905A68CF37D6EEA@PH0PR11MB5191.namprd11.prod.outlook.com>
 <CA+hUKG+okrN2e_GrWrYVGd8+uVznAUPNsjbgEtfY0rAdrwR-Vg@mail.gmail.com>
 <CA+hUKGKSQEewukGjw6o2FJeN9mkO29pCzmeXHnuPms=VXtjyuA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="w7W4/WOwq1fWV1EX"
Content-Disposition: inline
In-Reply-To: 
 <CA+hUKGKSQEewukGjw6o2FJeN9mkO29pCzmeXHnuPms=VXtjyuA@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/ZPqLfAk8n/HrB6G4%40paquier.xyz>
Precedence: bulk


--w7W4/WOwq1fWV1EX
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Sep 7, 2023 at 10:39=E2=80=AFPM James Pang (chaolpan)
<chaolpan(at)cisco(dot)com> wrote:
> (gdb) p RecordCacheArray
> $1 =3D (TupleDesc *) 0x7f5fac365d90
> (gdb) p RecordIdentifierArray
> $2 =3D (uint64 *) 0x0

Oh, yeah, this stack is broken.  You have been really unlucky to hit
that.  This can randomly cause any session to get stuck, and no need
for the extended query protocol here.

(I am not sure how, but my email server has somewhat not been able to
get the previous messages from James.  Anyway.)

On Fri, Sep 08, 2023 at 11:45:51AM +1200, Thomas Munro wrote:
> I think the lazy fix would be to re-order those allocations.  A
> marginally more elegant fix would be to merge the arrays, as in the
> attached.  Thoughts?

So, ensure_record_cache_typmod_slot_exists() would allocate the
initial RecordCacheArray and if it fails on the second one it keeps
RecordCacheArrayLen at 0.  When coming back again to this code path,
the second part of the routine causes an infinite loop because the
allocation has been done, but the tracked length is 0.  Fun.

This is broken since 4b93f57 where the second array has been
introduced.  Getting that fixed before 11 is EOL is nice as it was
introduced there, so good timing.

There is a repalloc_extended(), but I cannot get excited to use
MCXT_ALLOC_NO_OOM in this code path if there is a simpler method to
avoid this issue with a single allocation for the all information set.

+static RecordCacheArrayEntry * RecordCacheArray =3D NULL;=20

pgindent is annoyed by that..  typedefs.list has been updated in your
patch, so I guess that you missed one extra indentation after this is
refreshed.

Note that RememberToFreeTupleDescAtEOX() does something similar to the
type cache, and it uses the same approach as your patch.

+1 to your proposal of using a struct for the entries in the cache.
--
Michael

--w7W4/WOwq1fWV1EX
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmT6i3wACgkQnvQgOdby
QH3fvg/7B5EXZAXSxQoEFVF81srCTnpF+tDt8qP298FH9U60YuLo9CqI7IDJNL1v
cqrbyAd+DA5qHkkf68d8iUtNUPUmjCiN9780cU3Mq+oR5uFAk3tUPO+9pYw+uc/v
nA9oIKmoMTIg8u6xc3UGCINdeRtQMLhfwyNTCR8k8zbIVjbbitSuiIHodoo49M9T
DUp3q64T6SSjaMNEWkkyg7ZsEQ/IBnXjWTkYtImxOdE3bTOqx/ZsonUPigheZiJD
mJo308qxzzOm3hJwWTXDucmFQPsd3y6URHJSa3s0Me0AFaT/y3nt0P23t44aCak8
yGHwZXWP80iEB6mRDuXQlSSHhzrPZD3VPRR2GQ7NvveElzarD/zVBfI+FOZI+g15
uFZRUbqGJpbDG6sJC0pVJTg08yVms5npVGdzztV+xZI8KWCuks3VZqNqj0H3sRId
jg94PC5SkIi5HbbWEF74oIHzk8HMzMWnN4pAqIU4wu28TPdS4fuBdLVpZk2+XQq/
60OkqFkeJb7BN6Qk15lUKBzqi50IBIuz2iEVvV26WNaEREb+S5x/wuZosQVKcQcX
bcj7SlJRGiwGgZ8jUmtHckOot3sbDiz/p73bC0veSmnAxOMHaP9kzKCB4GpZ8rvi
hpVqrUm2bVQbWq7DyXoz1P72fGfgvlv9sgcWeflk6d5SOX7gSXo=
=zMn6
-----END PGP SIGNATURE-----

--w7W4/WOwq1fWV1EX--