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 1tad5r-003dI5-EI for pgsql-hackers@arkaria.postgresql.org; Wed, 22 Jan 2025 15:56:39 +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 1tad5q-001M3N-Cu for pgsql-hackers@arkaria.postgresql.org; Wed, 22 Jan 2025 15:56:38 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tad5q-001M3E-30 for pgsql-hackers@lists.postgresql.org; Wed, 22 Jan 2025 15:56:38 +0000 Received: from mail-il1-x12a.google.com ([2607:f8b0:4864:20::12a]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1tad5o-000vuO-02 for pgsql-hackers@lists.postgresql.org; Wed, 22 Jan 2025 15:56:37 +0000 Received: by mail-il1-x12a.google.com with SMTP id e9e14a558f8ab-3cf8e017abcso13429315ab.1 for ; Wed, 22 Jan 2025 07:56:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1737561396; x=1738166196; darn=lists.postgresql.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=PY45TFSKn/ZXMze57dwspl3+3pjpoaq2n2Of037skVY=; b=jvH9Woa//TqScC+pktNajROoh2de/uK9oczBXFBPpS2zAGLBeVDZ8pFAlFPeZoP8N/ GumuyYOeYEvWdCOwbd/HThauZ5kCVZAeHreW7mMsNPLGI38d+Rss/+e68IcZfDWxNXA0 5HD99cYcxn98XDnNyapFxnO45MdoMU1TcrGwfsxE6IbMySylNxcNzn3N1PQJzSipuuQe jhaYdLSBiC7KGVkL0tctaVW7M2+LH789xQe0l6U0yIcSRAXlHaAXv5rEO/AKFqSGlXM6 AXxTSPvu3BzePkq3lOLlaQzxIfg1Ri/ZNDa9TkZIQiAUotIu9DxVHD4/GQntZsV2gHuu 9CvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737561396; x=1738166196; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=PY45TFSKn/ZXMze57dwspl3+3pjpoaq2n2Of037skVY=; b=MFzXsj5jcAp0PWa0mBula16mTyBpSzYFdPlM0CnH8bSA7v3OJPbTGC4M6juu00QJYL A2x+1iI4S7bRWG0ArJM+IMsH30XmPJwHC5PoGB64ynlPyRiFJBO8mzCE4E2Ejperm/oQ rTLQvsokLcK5umRCI5/1QmHfjhgfbwUQvl3roKu8O5qs/Xt0PFIPnMGT2KZGP333oOTF UXef5VeVDu/3hqfu/ut5ngR2+vIPSjqtnVCPMrAdj4C9me3rkoKmyJ946+Y6B8c+IBky /uPYmW4npHXZespsW50HWW0nZ9w+JYmeUcbOGZVrtnO0j/M/A3QmiioB5G/IX/h7+DkS GkQw== X-Forwarded-Encrypted: i=1; AJvYcCWiVMbQQFqUujKid+5p1rJT8hYBdjIZOWeFHmuCROAu93z4tFNZzG/HX76awPm5XKq+E8Yd1LC95AvL0c/O@lists.postgresql.org X-Gm-Message-State: AOJu0YzRl8NrsojjggYpTehqxsZEkVdahSrO/3fqjD9lANyXe7zIq8OC Rtmz6+dL3CA3a7tXXyVKt7MPcdayWCvOIl9utzMvy+n2rWT4vMJr X-Gm-Gg: ASbGncsT0xxlmLIFN7NLCsP7YCX+TO7MlTd8ac1QqVAruJVeSdinDc88g4Zw7rzhx5d S/RStz89RDEaHgMdAwb0ga62boInFipVtkO7NtdvrggVMrGB16gx+0nrOrYvCHW/gFFlcq+NB/P 8ZnWA23Cth4EQzobF+i88qlb3+ZwIrAGmzGritjAl+Qy0c2FirEwsQs1ZB3qiD19Y/NwVDuOKLz qfHsHmThREoKLffftyEryWEzuEAIzSs4J4Rat0K2BnrNLY5bYOmq11pQivpoFhlhzth0f5369r7 GDTrrJNt9AN+DKhMXKwldc1lGnnB0XDhAY4n2zavwTfduUA4b8uEGDCWa5iR X-Google-Smtp-Source: AGHT+IHf0530yLWodIW/btWirHqz7s19YHejTDAm7KiuYvDSR5E//248CehZ8/FLewQ2Ptqcsym1BQ== X-Received: by 2002:a92:ca45:0:b0:3ce:7cca:db24 with SMTP id e9e14a558f8ab-3cf7441aad1mr162617415ab.13.1737561395761; Wed, 22 Jan 2025 07:56:35 -0800 (PST) Received: from nathan (162-195-168-172.lightspeed.stlsmo.sbcglobal.net. [162.195.168.172]) by smtp.gmail.com with ESMTPSA id 8926c6da1cb9f-4ea753f4fc9sm4151418173.3.2025.01.22.07.56.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 22 Jan 2025 07:56:35 -0800 (PST) Date: Wed, 22 Jan 2025 09:56:33 -0600 From: Nathan Bossart To: Andy Fan Cc: Andres Freund , Justin Pryzby , Maxim Orlov , Pavel Borisov , "Bossart, Nathan" , Maxim Orlov , pgsql-hackers@lists.postgresql.org Subject: Re: Pre-allocating WAL files Message-ID: References: <20220301144044.GG25269@telsasoft.com> <20220301150704.GA1030078@nathanxps13> <20220317231212.GB1415284@nathanxps13> <20220408203003.GA1630183@nathanxps13> <87sepc4zcg.fsf@163.com> <87o6zz4pld.fsf@163.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87o6zz4pld.fsf@163.com> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Wed, Jan 22, 2025 at 01:14:22AM +0000, Andy Fan wrote: > Andres Freund writes: >> FWIW, I've seen the fsyncs around recycling being a rather substantial >> bottleneck. To the point of the main benefit of larger segments being the >> reduction in number of fsyncs at the end of a checkpoint. I think we should >> be able to make the fsyncs a lot more efficient by batching them, first rename >> a bunch of files, then fsync them and the directory. The current pattern >> bascially requires a separate filesystem jouranl flush for each WAL segment. > > For education purpose, how to fsync files in batch? 'man fsync' tells me > user can only fsync one file each time. > > int fsync(int fd); > > The fsync manual seems not saying fsync on a directory would fsync all > the files under that directory. I think Andres means that we should wait until the end of recycling to fsync() the directory so that we aren't flushing it for every single recycled segment. This sort of batching approach could also work well with pre_sync_fname(), so that by the time we actually call fsync() on the files, it has very little to do. -- nathan