Re: Improve WALRead() to suck data directly from WAL buffers when possible
Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
From: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
To: Andres Freund <andres@anarazel.de>
Cc: Jeff Davis <pgsql@j-davis.com>, Dilip Kumar <dilipbalaut@gmail.com>, Kyotaro Horiguchi <horikyota.ntt@gmail.com>,
pgsql-hackers@lists.postgresql.org
Date: 2023-10-21T18:29:00Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Add XLogCtl->logInsertResult
- f3ff7bf83bce 17.0 cited
-
Add assert to WALReadFromBuffers().
- 9ecbf54075a9 17.0 landed
-
Read WAL directly from WAL buffers.
- 91f2cae7a4e6 17.0 landed
-
Additional write barrier in AdvanceXLInsertBuffer().
- 766571be1659 17.0 landed
-
Use 64-bit atomics for xlblocks array elements.
- c3a8e2a7cb16 17.0 landed
-
Don't trust unvalidated xl_tot_len.
- bae868caf222 17.0 cited
Attachments
- v12-0001-Allow-WAL-reading-from-WAL-buffers.patch (application/x-patch) patch v12-0001
- v12-0002-Add-test-module-for-verifying-WAL-read-from-WAL-.patch (application/x-patch) patch v12-0002
On Fri, Oct 20, 2023 at 10:19 PM Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com> wrote: > > On Thu, Oct 12, 2023 at 4:13 AM Andres Freund <andres@anarazel.de> wrote: > > > > On 2023-10-03 16:05:32 -0700, Jeff Davis wrote: > > > On Sat, 2023-01-14 at 12:34 -0800, Andres Freund wrote: > > > > One benefit would be that it'd make it more realistic to use direct > > > > IO for WAL > > > > - for which I have seen significant performance benefits. But when we > > > > afterwards have to re-read it from disk to replicate, it's less > > > > clearly a win. > > > > > > Does this patch still look like a good fit for your (or someone else's) > > > plans for direct IO here? If so, would committing this soon make it > > > easier to make progress on that, or should we wait until it's actually > > > needed? > > > > I think it'd be quite useful to have. Even with the code as of 16, I see > > better performance in some workloads with debug_io_direct=wal, > > wal_sync_method=open_datasync compared to any other configuration. Except of > > course that it makes walsenders more problematic, as they suddenly require > > read IO. Thus having support for walsenders to send directly from wal buffers > > would be beneficial, even without further AIO infrastructure. > > I'm attaching the v11 patch set with the following changes: > - Improved input validation in the function that reads WAL from WAL > buffers in 0001 patch. > - Improved test module's code in 0002 patch. > - Modernized meson build file in 0002 patch. > - Added commit messages for both the patches. > - Ran pgindent on both the patches. > > Any thoughts are welcome. I'm attaching v12 patch set with just pgperltidy ran on the new TAP test added in 0002. No other changes from that of v11 patch set. -- Bharath Rupireddy PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com