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.94.2) (envelope-from ) id 1tvaM4-0064Zm-Qu for pgsql-hackers@arkaria.postgresql.org; Fri, 21 Mar 2025 11:16:00 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1tvaM3-004hSR-I8 for pgsql-hackers@arkaria.postgresql.org; Fri, 21 Mar 2025 11:15:59 +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.94.2) (envelope-from ) id 1tvaM3-004hSJ-9D for pgsql-hackers@lists.postgresql.org; Fri, 21 Mar 2025 11:15:59 +0000 Received: from mail-pl1-x62b.google.com ([2607:f8b0:4864:20::62b]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1tvaM1-000JE8-0n for pgsql-hackers@postgresql.org; Fri, 21 Mar 2025 11:15:58 +0000 Received: by mail-pl1-x62b.google.com with SMTP id d9443c01a7336-2243803b776so8069345ad.0 for ; Fri, 21 Mar 2025 04:15:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1742555755; x=1743160555; darn=postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=BU1wXQkdWRCVrlCAFQVgFH8G7rHEVtZT1lfodlz79L8=; b=LJKgV7daKLws4AS+WYNlWnHuSEzjGzm6TrChHlohxyjfarUaZgtSHqoJUb/NS/wRo2 d914lTXKrI30xmVrw1A0uqVROJ0s+mDu7tpqWwUnBwjOBkW1lyyMAg7YR5vzWC3URpxG 5b/Au7Odk0VPZ/elWcJz8pbnYrR8iwGQhlgPnj4SQ9aj+LhEIC2DbW2TG0i2c49m5112 Zn/7LX+M9/4GuF4lwAxJsjaAd0GJ3pmIk/jN/OlavY7cA7BJlK2n4Hu+kqDTSDWVdkOv LOKxm12UQWPwOtRk89yJ/W4FrPjrNfGF/rsiTDwj7Y43zKeld6yZMKWNbDYHB11e9I3U LwvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742555755; x=1743160555; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=BU1wXQkdWRCVrlCAFQVgFH8G7rHEVtZT1lfodlz79L8=; b=ORbBcfiIY8h30TUO6BYl7NusFbSZpG2+Qv3IUXKFpgd8lFrGVC5NDrhFkOgGKLCkF7 Ri1LhpVxFAVm2fdcOENkaUk/+3ln+JGbNBdJ+kAW8/B+g6dvbeLEBfuX5ITo2sxgtWWM nSrEWYYhzH3/CIn6tO6uloED+qWY9sYpv0T4Dh6TPyI68XC06Hqwz+pOyZVPSb65M6GV Pn9GveprNHdcsHXESuN33+dswvtFCxHkj8+ImLDsJqdXHjrlDYiiyhJh4vh0jw7jar0D vOgasdOz2RQDn15HVmCEedLW+8k/SgZgFojKoHxbgZEOxOeyI8I8e7HSzU+ABISOR6Zw +vEQ== X-Forwarded-Encrypted: i=1; AJvYcCVseRG5TunOJji+kp9Cv9U+JEXA3OUksv7vDzn+3jBaeBtptR/xRhF28bT/he7E9dq+gXHSQdG/qcky709S@postgresql.org X-Gm-Message-State: AOJu0YwANCovIiZDyBIqgYyNS+VlcF7RYFsyNbtgHpAo7wbiubX97qsS gS9wJ5aW85LrgGzx7ZcWqU1W45ZnzSiEpuESg6JBEVMY5I5gKg7c6Yxhzv98B9X0/vXPA+oGwLX X90Q1QW0rEqjMehwj77W7iNcxPKQ= X-Gm-Gg: ASbGncuOJvXAKAV07LMGgWkHHAF8xn7ahlesnmdqePbphPJEMlvcVShg/ZWkrJP3mJ1 0+3qAV99+6Nk4BIEdWyA+ZufjJKhk0dZYppHm4Bz05bf/j7M2hNeyAecCgZ4BSVm+KFYNgk740N /m/UL4A99vMtMp75Tuj23x7vuNo1k= X-Google-Smtp-Source: AGHT+IEq7m7Rcnd4PhuzGfMJgFcOX4RaAO1TmcT41S+Rk9bf7N7dlmj2B8cVlsUPlT5HV5Rj/axAQUbsfOuGZwmr+uI= X-Received: by 2002:a17:903:292:b0:21f:1bd:efd4 with SMTP id d9443c01a7336-22780c7ef1emr51144305ad.19.1742555755050; Fri, 21 Mar 2025 04:15:55 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Nazir Bilal Yavuz Date: Fri, 21 Mar 2025 14:15:43 +0300 X-Gm-Features: AQ5f1Jr0oMkM4v0wRjNBRgAHfoMFSfEfOkJjBSU-cHv2s32q25QeymmmqKtBZgg Message-ID: Subject: Re: Improve monitoring of shared memory allocations To: Rahila Syed Cc: Andres Freund , PostgreSQL-development Content-Type: text/plain; charset="UTF-8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi, On Wed, 12 Mar 2025 at 13:46, Rahila Syed wrote: > I have now made the changes uniformly across shared and non-shared hash tables, > making the code fix look cleaner. I hope this aligns with your suggestions. > Please find attached updated and rebased versions of both patches. Thank you for working on this! I have a couple of comments, I have only reviewed 0001 so far. You may need to run pgindent, it makes some changes. diff --git a/src/backend/utils/hash/dynahash.c b/src/backend/utils/hash/dynahash.c index cd5a00132f..3bdf3d6fd5 100644 --- a/src/backend/utils/hash/dynahash.c +++ b/src/backend/utils/hash/dynahash.c + /* + * If table is shared, calculate the offset at which to find the the + * first partition of elements + */ + + nsegs = compute_buckets_and_segs(nelem, &nbuckets, hctl->num_partitions, hctl->ssize); Blank line between the comment and the code. + bool element_alloc = true; + Size elementSize = MAXALIGN(sizeof(HASHELEMENT)) + MAXALIGN(info->entrysize); It looks odd to me that camelCase and snake_case are used together but it is already used like that in this file; so I think it should be okay. /* * allocate some new elements and link them into the indicated free list */ -static bool -element_alloc(HTAB *hashp, int nelem, int freelist_idx) +static HASHELEMENT * +element_alloc(HTAB *hashp, int nelem) Comment needs an update. This function no longer links elements into the free list. +static int +compute_buckets_and_segs(long nelem, int *nbuckets, long num_partitions, long ssize) +{ ... + /* + * In a partitioned table, nbuckets must be at least equal to + * num_partitions; were it less, keys with apparently different partition + * numbers would map to the same bucket, breaking partition independence. + * (Normally nbuckets will be much bigger; this is just a safety check.) + */ + while ((*nbuckets) < num_partitions) + (*nbuckets) <<= 1; I have some worries about this function, I am not sure what I said below has real life implications as you already said 'Normally nbuckets will be much bigger; this is just a safety check.'. 1- num_partitions is long and nbuckets is int, so could there be any case where num_partition is bigger than MAX_INT and cause an infinite loop? 2- Although we assume both nbuckets and num_partition initialized as the same type, (*nbuckets) <<= 1 will cause an infinite loop if num_partition is bigger than MAX_TYPE / 2. So I think that the solution is to confirm that num_partition < MAX_NBUCKETS_TYPE / 2, what do you think? -- Regards, Nazir Bilal Yavuz Microsoft