Horton

Re: Refactoring the checkpointer's fsync request queue

Thomas Munro <thomas.munro@gmail.com>

View thread View on postgr.es
From: Thomas Munro <thomas.munro@gmail.com>
To: Shawn Debnath <sdn@amazon.com>
Cc: Robert Haas <robertmhaas@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Andres Freund <andres@anarazel.de>, Dmitry Dolgov <9erthalion6@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2019-04-04T01:01:14Z
Lists: pgsql-hackers

Attachments

On Thu, Apr 4, 2019 at 11:39 AM Thomas Munro <thomas.munro@gmail.com> wrote:
> ... Perhaps
> that is an argument for putting the sync handler number *inside* the
> FileTag, since we currently intend to do that with smgr IDs in
> BufferTag (stealing space from ForkNumber).

Here is a version like that.  I like it better this way, and the extra
space can be clawed back by using 16 bit types to hold the fork number
and sync handler number.

Here again is the straw-man 0002 patch updated to show how it might
look for another potential user.

-- 
Thomas Munro
https://enterprisedb.com

Commits

  1. Fix bugs in mdsyncfiletag().

  2. Refactor the fsync queue for wider use.

  3. Don't forget about failed fsync() requests.

  4. PANIC on fsync() failure.

  5. Move LockClauseStrength, LockWaitPolicy into new file nodes/lockoptions.h.

  6. Add new file for checkpointer.c

  7. Split work of bgwriter between 2 processes: bgwriter and checkpointer.

  8. Install infrastructure for shared-memory free space map. Doesn't actually