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 1u0hek-006Ew3-Cc for pgsql-hackers@arkaria.postgresql.org; Fri, 04 Apr 2025 14:04:26 +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 1u0hei-000V67-Na for pgsql-hackers@arkaria.postgresql.org; Fri, 04 Apr 2025 14:04:24 +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 1u0hei-000V5y-A6 for pgsql-hackers@lists.postgresql.org; Fri, 04 Apr 2025 14:04:24 +0000 Received: from meesny.iki.fi ([195.140.195.201]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1u0hef-003MeY-1n for pgsql-hackers@lists.postgresql.org; Fri, 04 Apr 2025 14:04:23 +0000 Received: from [192.168.1.112] (iptv-hkibng21-58c090-167.dhcp.inet.fi [88.192.144.167]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: hlinnaka) by meesny.iki.fi (Postfix) with ESMTPSA id 4ZTgMR1ZnvzyQX; Fri, 4 Apr 2025 17:04:19 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1743775459; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=kh6gkkJ1b+5PTtRLdiXHOmS/AedDVwNcwZbZCFwYcIg=; b=lH00jg9Y/sS7a7WFuBHZPLpbYYuPZ8We3YaFHuFKjXyOopUPOBiy54hQv+u/66ocqIBKDC rWXOqsRipExzTjEwMXIgJb3f1njT5t1jStpc/pvzd7c3kF+hKlVRvMXJmxJu/avmkkLuFe PdjGHnbf9oQ1UaBavVK6QSjli5fI0J4= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1743775459; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=kh6gkkJ1b+5PTtRLdiXHOmS/AedDVwNcwZbZCFwYcIg=; b=HT8I+I6+Hk8Dwmuqtce3PA92/gkZzN4JIGWTmtMLLK+q3of4RoLGOPw94m66B6TX7tfU/f TNxE3OUjHAq29u6UyMZlcNVCqb9nzN6L0hImomUl9ifFjud4VYCuBJNzIxiq7oJzHO77GX zmKh7N6lcaalZuhMuZl9HyY4/USYjzw= ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=hlinnaka smtp.mailfrom=hlinnaka@iki.fi ARC-Seal: i=1; s=meesny; d=iki.fi; t=1743775459; a=rsa-sha256; cv=none; b=h50hBQoWM22JDHcUhVCtwfnAi8Qn+bDeBCc+YQH1kY/LA7uWird23lSp4L4t9AhEDiM29g yJCtFBiZi2FuW4OoJjV53waa8eSMIZ9fve0/jfmw4rv+k4X8ksgwhEYd647J+ElyTg86vi aF1xStx6Ghf2n6V21g4q6BAf8o+myto= Message-ID: <71abd264-1911-46a0-a25b-079a7cfa577a@iki.fi> Date: Fri, 4 Apr 2025 17:04:18 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: autoprewarm_dump_now To: =?UTF-8?B?0JTQsNGA0YzRjyDQqNCw0L3QuNC90LA=?= , pgsql-hackers@lists.postgresql.org References: Content-Language: en-US From: Heikki Linnakangas In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 04/04/2025 16:40, Дарья Шанина wrote: > Hello everyone! > I have a question. > > What would be better for the function autoprewarm_dump_now in case when > we need to allocate memory that exceeds 1 GB: Hmm, so if I counted right, sizeof(BlockInfoRecord) == 20 bytes, which means that you can fit about 409 GB worth of buffers in a 1 GB allocation. So autoprewarm will currently not work with shared_buffers > 409 GB. That's indeed quite unfortunate. > 1) allocate enough memory for the entire shared_buffer array > (1..NBuffers) using palloc_extended; That would be a pretty straightforward fix. > 2) allocate the maximum of currently possible memory (1 GB) using an > ordinary palloc. That'd put an upper limit on how much is prewarmed. It'd be a weird limitation. And prewarming matters the most with large shared_buffers. 3) Don't pre-allocate the array, write it out in a streaming fashion. Unfortunately the file format doesn't make that easy: the number of entries is at the beginning of the file. You could count the entries beforehand, but the buffers can change concurrently. You could write a placeholder first, and seek back to the beginning of the file to fill in the real number at the end. The problem with that is that the number of bytes needed for the count itself varies. I suppose we could write some spaces as placeholders to accommodate the max count. In apw_load_buffers(), we also load the file into (DSM) memory. There's no similar 1 GB limit in dsm_create(), but I think it's a bit unfortunate that the array needs to be allocated upfront upon loading. In short, ISTM the easy answer here is "use palloc_extended". But there's a lot of room for further optimizations. -- Heikki Linnakangas Neon (https://neon.tech)