Re: Relation bulk write facility
Noah Misch <noah@leadboat.com>
From: Noah Misch <noah@leadboat.com>
To: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: Peter Smith <smithpb2250@gmail.com>, Robert Haas <robertmhaas@gmail.com>, vignesh C <vignesh21@gmail.com>, Andres Freund <andres@anarazel.de>, pgsql-hackers <pgsql-hackers@postgresql.org>, Melanie Plageman <melanieplageman@gmail.com>
Date: 2024-07-03T03:41:31Z
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 →
-
Relax fsyncing at end of a bulk load that was not WAL-logged
- 68f199cea3b1 17.0 landed
- 077ad4bd76b1 18.0 landed
-
Fix cross-version upgrade tests after f0827b443.
- e8aecc5c2ce1 17.0 landed
-
Remove AIX support
- 0b16bb8776bb 17.0 landed
-
Fix compiler warning on typedef redeclaration
- d360e3cc60e3 17.0 landed
-
Introduce a new smgr bulk loading facility.
- 8af256524893 17.0 landed
On Tue, Jul 02, 2024 at 02:42:50PM +0300, Heikki Linnakangas wrote: > On 02/07/2024 02:24, Noah Misch wrote: > > On Tue, Jul 02, 2024 at 12:53:05AM +0300, Heikki Linnakangas wrote: > log_newpage_range() loads the pages to the buffer > cache and dirties them. That kinds of sucks actually, I wish it didn't need > to dirty the buffers. Agreed. > > > Fortunately, fsync() on a file that's already flushed to disk is pretty > > > cheap. > > > > Yep. I'm more concerned about future readers wondering why the function is > > using LSNs to decide what to do about data that doesn't appear in WAL. A > > comment could be another way to fix that, though. > > Agreed, this is all very subtle, and deserves a good comment. What do you > think of the attached? Looks good. Thanks. pgindent doesn't preserve all your indentation, but it doesn't make things objectionable, either.