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 1ta4zV-00FxJy-RA for pgsql-hackers@arkaria.postgresql.org; Tue, 21 Jan 2025 03:31:50 +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 1ta4zV-00AU8v-0C for pgsql-hackers@arkaria.postgresql.org; Tue, 21 Jan 2025 03:31:49 +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 1ta4zU-00AU8n-9V for pgsql-hackers@lists.postgresql.org; Tue, 21 Jan 2025 03:31:48 +0000 Received: from m16.mail.163.com ([220.197.31.2]) by magus.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1ta4zO-000eAT-0r for pgsql-hackers@lists.postgresql.org; Tue, 21 Jan 2025 03:31:47 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=From:Subject:Date:Message-ID:MIME-Version: Content-Type; bh=ZIOM3Yk9YnCS+7y160pYrJQIrNlJpZAeFn+y3MxRH8o=; b=BsZMIfko7UhDbg2mjWhXW+7t/+kHZ7S1sHkIm3LDJGigPmLiwOAkp/zmdhcE5o CdyOrv0tDrT5u7mjhHZUtBlkXVhQc6AfdudecV20VJmc4CfNYKp+jFIn8/W1es9y i+1iJcavo82t+9RL1wPQEwDW3zHfv1IqMT6pydWcLNsFo= Received: from lovely-coding (unknown []) by gzga-smtp-mtada-g0-3 (Coremail) with SMTP id _____wC3Ef4PFY9ngNa6HA--.32977S3; Tue, 21 Jan 2025 11:31:28 +0800 (CST) From: Andy Fan To: Nathan Bossart Cc: Justin Pryzby , Maxim Orlov , Pavel Borisov , "Bossart, Nathan" , Maxim Orlov , Andres Freund , pgsql-hackers@lists.postgresql.org Subject: Re: Pre-allocating WAL files In-Reply-To: <20220408203003.GA1630183@nathanxps13> (Nathan Bossart's message of "Fri, 8 Apr 2022 13:30:03 -0700") References: <20201225200953.jjkrytlrzojbndh5@alap3.anarazel.de> <51BAAB3B-9D3C-4155-B125-42E4F06DCDF4@amazon.com> <163352276350.15435.3988688227048304232.pgcf@coridan.postgresql.org> <20220301144044.GG25269@telsasoft.com> <20220301150704.GA1030078@nathanxps13> <20220317231212.GB1415284@nathanxps13> <20220408203003.GA1630183@nathanxps13> Date: Tue, 21 Jan 2025 03:31:27 +0000 Message-ID: <87sepc4zcg.fsf@163.com> MIME-Version: 1.0 Content-Type: text/plain X-CM-TRANSID:_____wC3Ef4PFY9ngNa6HA--.32977S3 X-Coremail-Antispam: 1Uf129KBjvJXoW7Zr1rWr18Xw1xuF1xWrW3Wrg_yoW8Ar45p3 9xWryYyFs5Kr4xCrnavw1UCF1ru3ykJry3Gws8t34IvrsxGrnavF9agFs5tFWUCr93X3WY qrW2ya47Ja4rZaDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x0zRAwIkUUUUU= X-Originating-IP: [219.151.179.207] X-CM-SenderInfo: x2klx3xlid0iqsrtqiywtou0bp/1tbioBjbU2ePEqMoXQABsd List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi Nathan, Come from [0] and thanks for working on this. Here are some design review/question after my first going through the patch. 1. walwriter vs checkpointer? I prefer to walwriter for now because.. a. checkpointer is hard to do it in a timely manner either because checkpoint itself may take a long time or the checkpoint_timeout is much bigger than commit_delay. but walwriter could do this timely. I think this is an important consideration for this feature. b. We want walwriter to run with low latency to flush out async commits. This is true, but preallocating a wal doesn't increase the latency too much. After all, even user uses the aysnc commit, the walfile allocating is done by walwriter already in our current implementation. 2. How many xlogfile should be preallocated by checkpointer/walwriter once. In your patch it is controled by wal-preallocate-max-size. How about just preallocate *the next one* xlogfile for the simplification purpose? 3. Why is the purpose of preallocated_segments directory? what in my mind is we just prellocate the normal filename so that XLogWrite could open it directly. This is same as what wal_recycle does and we can reuse the same strategy to clean up them if they are not needed anymore. So the poc in my mind for this feature is: - keep track the latested reallocated (by wal_recycle or preallocated) logfile in XLogCtl. - logwriter check current wal insert_pos and prellocate the *next one* walfile if it doesn't preallocated yet. - we need to handle race condition carefully between wal_recycle, user backend and preallocation. [0] https://www.postgresql.org/message-id/Z46BwCNAEjLyW85Z%40nathan -- Best Regards Andy Fan