Horton

Re: Refactoring the checkpointer's fsync request queue

Kevin Grittner <kgrittn@gmail.com>

View thread View on postgr.es
From: Kevin Grittner <kgrittn@gmail.com>
To: Andres Freund <andres@anarazel.de>
Cc: Thomas Munro <thomas.munro@enterprisedb.com>, Dmitry Dolgov <9erthalion6@gmail.com>, Robert Haas <robertmhaas@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>, Shawn Debnath <sdn@amazon.com>
Date: 2019-01-22T20:53:11Z
Lists: pgsql-hackers 
On Tue, Jan 22, 2019 at 2:38 PM Andres Freund <andres@anarazel.de> wrote:

> close() doesn't trigger an fsync() in general

What sort of a performance hit was observed when testing the addition
of fsync or fdatasync before any PostgreSQL close() of a writable
file, or have we not yet checked that?

> https://postgr.es/m/20180427222842.in2e4mibx45zdth5%40alap3.anarazel.de
> is, I think, a good overview, with a bunch of links.

Thanks!  Will review.

-- 
Kevin Grittner
VMware vCenter Server
https://www.vmware.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