| From: | 陈宗志 <baotiao(at)gmail(dot)com> |
|---|---|
| To: | devops(at)ww-it(dot)cn |
| Cc: | Robert Treat <rob(at)xzilla(dot)net>, Jakub Wartak <jakub(dot)wartak(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: [PROPOSAL] Doublewrite Buffer as an alternative torn page protection to Full Page Write |
| Date: | 2026-02-27 19:11:01 |
| Message-ID: | CAGbZs7grxqvQXrLFZuz4rhRb5jMOnrJ3YG4EHuoHej-UhJwWNg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Sami Imseih | 2026-02-27 19:11:38 | Re: Fix bug in multixact Oldest*MXactId initialization and access |
| Previous Message | Ayush Tiwari | 2026-02-27 18:59:20 | tid_blockno() and tid_offset() accessor functions |