RE: [PoC] Non-volatile WAL buffer

From: Takashi Menjo <takashi(dot)menjou(dot)vg(at)hco(dot)ntt(dot)co(dot)jp>
To: 'Heikki Linnakangas' <hlinnaka(at)iki(dot)fi>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: RE: [PoC] Non-volatile WAL buffer
Date: 2020-01-27 07:01:15
Message-ID: 000301d5d4df$9129f820$b37de860$@hco.ntt.co.jp_1
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello Heikki,

> I have the same comments on this that I had on the previous patch, see:
>
> https://www.postgresql.org/message-id/2aec6e2a-6a32-0c39-e4e2-aad854543aa8%40iki.fi

Thanks. I re-read your messages [1][2]. What you meant, AFAIU, is how
about using memory-mapped WAL segment files as WAL buffers, and switching
CPU instructions or msync() depending on whether the segment files are on
PMEM or not, to sync inserted WAL records.

It sounds reasonable, but I'm sorry that I haven't tested such a program
yet. I'll try it to compare with my non-volatile WAL buffer. For now, I'm
a little worried about the overhead of mmap()/munmap() for each WAL segment
file.

You also told a SIGBUS problem of memory-mapped I/O. I think it's true for
reading from bad memory blocks, as you mentioned, and also true for writing
to such blocks [3]. Handling SIGBUS properly or working around it is future
work.

Best regards,
Takashi

[1] https://www.postgresql.org/message-id/83eafbfd-d9c5-6623-2423-7cab1be3888c%40iki.fi
[2] https://www.postgresql.org/message-id/2aec6e2a-6a32-0c39-e4e2-aad854543aa8%40iki.fi
[3] https://pmem.io/2018/11/26/bad-blocks.htm

--
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 Surafel Temesgen 2020-01-27 07:15:23 Re: can we use different function in place of atoi in vacuumdb.c file
Previous Message Masahiko Sawada 2020-01-27 06:59:58 Re: error context for vacuum to include block number