DomainKey-Signature: a=rsa-sha1; c=nofws; d=ww-it.cn; h=message-id:date
	:mime-version:subject:to:cc:references:from:in-reply-to
	:content-type:content-transfer-encoding; q=dns; s=default; b=uXX
	DO8CSF1g7n4OTQD/bvHMCDX4RtZM70L2pN3EV2QpHq45kHdOfyGciQN3wR0L5u9R
	DSbbhbuMCKDeRdgzM7mQpEBVC771hh/C22dkOVxoIlh5zKFYFINN6WY7Vpxk80sl
	u/kKakxQIaeBoC+1F4Bfes7tllt64eZTzk80KzNI=
Message-ID: <99e3e7e0-b2b7-4f4e-bb65-94213c2a9826@ww-it.cn>
Date: Sat, 28 Feb 2026 08:44:52 +0800
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PROPOSAL] Doublewrite Buffer as an alternative torn page
 protection to Full Page Write
To: =?UTF-8?B?6ZmI5a6X5b+X?= <baotiao@gmail.com>
Cc: Robert Treat <rob@xzilla.net>,
 Jakub Wartak <jakub.wartak@enterprisedb.com>, pgsql-hackers@postgresql.org
References: <CAGbZs7g+x0qUhe9Xdf_SqC4U5HGMnM=rnuvoc+vCR4Hbq1X=wA@mail.gmail.com>
 <CAKZiRmyN40=WW27Mnkj_zO3FvYn8fcoFwnQ+a=+W6zymqPr0vQ@mail.gmail.com>
 <CABV9wwPp8Zn3-9B4ciYTEAuBueMUv5BoRAvRw34F3yrNS4XOUw@mail.gmail.com>
 <CAGbZs7j9ESVUF2kpqndy4NXgVevnaHJb7144NFC6WK08yXo1Eg@mail.gmail.com>
 <CAGjGUAJRVnbzj8jJqHYS-91HEojLeTFPgpaYDBsUAbG3cJ0o2g@mail.gmail.com>
 <CAGbZs7j2x4Ld7OztM1wrdXD9-PLwYpQXiw1SfKaws85nnHewcA@mail.gmail.com>
 <CAGbZs7grxqvQXrLFZuz4rhRb5jMOnrJ3YG4EHuoHej-UhJwWNg@mail.gmail.com>
Content-Language: en-US
From: Tony ZHU <devops@ww-it.cn>
In-Reply-To: <CAGbZs7grxqvQXrLFZuz4rhRb5jMOnrJ3YG4EHuoHej-UhJwWNg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://www.postgresql.org/message-id/99e3e7e0-b2b7-4f4e-bb65-94213c2a9826%40ww-it.cn>
Precedence: bulk

Hi

ZongZhi, Thanks for feedback.


I have read prior thread on this email, and know your settings, when did 
the testing, checkpoint_timeout set to 30s is too small, it's not a 
reasonable setting ,

the value of checkpoint_timeout is determined by shared_buffers and the 
workload, in real product environment, we usually set it to 30min or 
longer, even 1 hours, when the setting is correct, FPW will not be a 
problem or issue.

other issue is introduced by double write that is the recovery procedure 
and replications, it is not a small project.

if you really focus on the write or read latency, I would like to advice 
you to take a look for OrioleDB storage engine, I believe that's the 
correct direction. it is more efficient reads and writes, resolving many 
known overheads and issues in PostgreSQL


Regards

Tony


On 2026/2/28 03:11, 陈宗志 wrote:
> Hi Tony,
>
>> Personally believe that the Double Write is very smart for MySQL InnoDB,
>> but not a good ideal for Postgres, currently, WAL is the best solution
>> for Postgres,
>> maybe the next generation log system for Postgres could use OrioleDB's
>> storage engine.
> Just to clarify from a technical perspective, both MySQL and PostgreSQL
> use Write-Ahead Logging (WAL) as their fundamental transaction logging
> mechanism, so there is no difference in that regard.
>
> The comparison here is specifically between Full-Page Writes (FPW) and
> the Double Write Buffer (DWB). Neither of these concepts conflicts with
> or replaces the core WAL design. Instead, both are simply different
> techniques implemented to solve the exact same issue: preventing torn
> pages during a crash.
>
> My proposal is aimed at discussing the performance tradeoffs and
> implementation details between these two specific torn-page protection
> mechanisms, rather than replacing WAL itself.
>
> Regards,
> Baotiao