pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Michael Paquier <michael@paquier.xyz>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: James Pang (chaolpan) <chaolpan@cisco.com>
Cc: PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Subject: Re: FW: query pg_stat_ssl hang 100%cpu
Date: Fri, 8 Sep 2023 11:48:28 +0900
Message-ID: <ZPqLfAk8n/HrB6G4@paquier.xyz> (raw)
In-Reply-To: <CA+hUKGKSQEewukGjw6o2FJeN9mkO29pCzmeXHnuPms=VXtjyuA@mail.gmail.com>
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>

On Thu, Sep 7, 2023 at 10:39 PM James Pang (chaolpan)
<chaolpan(at)cisco(dot)com> wrote:
> (gdb) p RecordCacheArray
> $1 = (TupleDesc *) 0x7f5fac365d90
> (gdb) p RecordIdentifierArray
> $2 = (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 = NULL; 

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

Attachments:

  [application/pgp-signature] signature.asc (832B, ../ZPqLfAk8n%2FHrB6G4@paquier.xyz/2-signature.asc)
  download

view thread (19+ messages)  latest in thread

Message-ID: <ZPqLfAk8n/HrB6G4@paquier.xyz>
Permalink:  ../ZPqLfAk8n%2FHrB6G4@paquier.xyz/
Also on:    postgresql.org/message-id/ZPqLfAk8n/HrB6G4@paquier.xyz

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: michael@paquier.xyz, thomas.munro@gmail.com, chaolpan@cisco.com, pgsql-bugs@lists.postgresql.org
  Subject: Re: FW: query pg_stat_ssl hang 100%cpu
  In-Reply-To: <ZPqLfAk8n/HrB6G4@paquier.xyz>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox