RE: [PoC] Non-volatile WAL buffer

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

In response to

Responses

Browse pgsql-hackers by date

  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