RE: [PoC] Non-volatile WAL buffer - Mailing list pgsql-hackers

From Takashi Menjo
Subject RE: [PoC] Non-volatile WAL buffer
Date
Msg-id 001701d5d5b4$a8f36290$fada27b0$@hco.ntt.co.jp_1
Whole thread Raw
In response to Re: [PoC] Non-volatile WAL buffer  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [PoC] Non-volatile WAL buffer  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Hello Robert,

I think our concerns are roughly classified into two:

 (1) Performance
 (2) Consistency

And your "different concern" is rather into (2), I think.

I'm also worried about it, but I have no good answer for now.  I suppose mmap(flags|=MAP_SHARED) called by multiple
backendprocesses for the same file works consistently for both PMEM and non-PMEM devices.  However, I have not found
anyevidence such as specification documents yet. 

I also made a tiny program calling memcpy() and msync() on the same mmap()-ed file but mutually distinct address range
inparallel, and found that there was no corrupted data.  However, that result does not ensure any consistency I'm
worriedabout.  I could give it up if there *were* corrupted data... 

So I will go to (1) first.  I will test the way Heikki told us to answer whether the cost of mmap() and munmap() per
WALsegment, etc, is reasonable or not.  If it really is, then I will go to (2). 

Best regards,
Takashi

--
Takashi Menjo <takashi.menjou.vg@hco.ntt.co.jp>
NTT Software Innovation Center






pgsql-hackers by date:

Previous
From: Dilip Kumar
Date:
Subject: Re: PATCH: logical_work_mem and logical streaming of largein-progress transactions
Next
From: Amit Langote
Date:
Subject: Re: Autovacuum on partitioned table