From: | Takashi Menjo <takashi(dot)menjou(dot)vg(at)hco(dot)ntt(dot)co(dot)jp> |
---|---|
To: | 'Robert Haas' <robertmhaas(at)gmail(dot)com> |
Cc: | 'Heikki Linnakangas' <hlinnaka(at)iki(dot)fi>, pgsql-hackers(at)postgresql(dot)org |
Subject: | RE: [PoC] Non-volatile WAL buffer |
Date: | 2020-01-28 08:26:38 |
Message-ID: | 001701d5d5b4$a8f36290$fada27b0$@hco.ntt.co.jp_1 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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 backend processes for the same file works consistently for both PMEM and non-PMEM devices. However, I have not found any evidence 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 in parallel, and found that there was no corrupted data. However, that result does not ensure any consistency I'm worried about. 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 WAL segment, etc, is reasonable or not. If it really is, then I will go to (2).
Best regards,
Takashi
--
Takashi Menjo <takashi(dot)menjou(dot)vg(at)hco(dot)ntt(dot)co(dot)jp>
NTT Software Innovation Center
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Langote | 2020-01-28 08:52:27 | Re: Autovacuum on partitioned table |
Previous Message | Dilip Kumar | 2020-01-28 08:25:11 | Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions |