RE: [HACKERS][PATCH] Applying PMDK to WAL operations for persistentmemory

From: Robert Haas [mailto:robertmhaas@gmail.com]
> If I understand correctly, those results are all just pg_test_fsync results.
> That's not reflective of what will happen when the database is actually
> running.  When you use open_sync or open_datasync, you force WAL write and
> WAL flush to happen simultaneously, instead of letting the WAL flush be
> delayed.

Yes, that's pg_test_fsync output.  Isn't pg_test_fsync the tool to determine the value for wal_sync_method?  Is this
manualmisleading?
 

https://www.postgresql.org/docs/devel/static/pgtestfsync.html
--------------------------------------------------
pg_test_fsync - determine fastest wal_sync_method for PostgreSQL

pg_test_fsync is intended to give you a reasonable idea of what the fastest wal_sync_method is on your specific system,
aswell as supplying diagnostic information in the event of an identified I/O problem.
 
--------------------------------------------------


Anyway, I'll use pgbench, and submit a patch if open_datasync is better than fdatasync.  I guess the current tweak of
makingfdatasync the default is a holdover from the era before ext4 and XFS became prevalent.
 


> I don't have the results handy at the moment.  We found it to be faster
> on a database benchmark where the WAL was stored on an NVRAM device.

Oh, NVRAM.  Interesting.  Then I'll try open_datasync/fdatasync comparison on HDD and SSD/PCie flash with pgbench.

Regards
Takayuki Tsunakawa