Hi, Rebased, and added the patches below into the patchset.
- (0006) Let wal_pmem_map be constant unless --with-libpmem wal_pmem_map never changes from false in that case, so let it be constant. Thanks, Matthias! - (0007) Ensure WAL mappings before assertion This fixes SIGSEGV abortion in GetXLogBuffer when --enable-cassert. - (0008) Update document This adds a new entry for wal_pmem_map in the section Write Ahead Log -> Settings. Best regards, Takashi On Fri, Oct 8, 2021 at 5:07 PM Takashi Menjo <takashi.me...@gmail.com> wrote: > > Hello Matthias, > > Thank you for your comment! > > > > [ v3-0002-Add-wal_pmem_map-to-GUC.patch ] > > > +extern bool wal_pmem_map; > > > > A lot of the new code in these patches is gated behind this one flag, > > but the flag should never be true on !pmem systems. Could you instead > > replace it with something like the following? > > > > +#ifdef USE_LIBPMEM > > +extern bool wal_pmem_map; > > +#else > > +#define wal_pmem_map false > > +#endif > > > > A good compiler would then eliminate all the dead code from being > > generated on non-pmem builds (instead of the compiler needing to keep > > that code around just in case some extension decides to set > > wal_pmem_map to true on !pmem systems because it has access to that > > variable). > > That sounds good. I will introduce it in the next update. > > > > [ v3-0004-Map-WAL-segment-files-on-PMEM-as-WAL-buffers.patch ] > > > + if ((uintptr_t) addr & ~PG_DAX_HUGEPAGE_MASK) > > > + elog(WARNING, > > > + "file not mapped on DAX hugepage boundary: path \"%s\" addr > > > %p", > > > + path, addr); > > > > I'm not sure that we should want to log this every time we detect the > > issue; It's likely that once it happens it will happen for the next > > file as well. Maybe add a timeout, or do we generally not deduplicate > > such messages? > > Let me give it some thought. I have believed this WARNING is most > unlikely to happen, and is mutually independent from other happenings. > I will try to find a case where the WARNING happens repeatedly; or I > will de-duplicate the messages if it is easier. > > Best regards, > Takashi > > -- > Takashi Menjo <takashi.me...@gmail.com> -- Takashi Menjo <takashi.me...@gmail.com>
v4-0001-Add-with-libpmem-option-for-PMEM-support.patch
Description: Binary data
v4-0002-Add-wal_pmem_map-to-GUC.patch
Description: Binary data
v4-0003-Export-InstallXLogFileSegment.patch
Description: Binary data
v4-0005-WAL-statistics-in-cases-of-wal_pmem_map-true.patch
Description: Binary data
v4-0004-Map-WAL-segment-files-on-PMEM-as-WAL-buffers.patch
Description: Binary data
v4-0006-Let-wal_pmem_map-be-constant-unless-with-libpmem.patch
Description: Binary data
v4-0007-Ensure-WAL-mappings-before-assertion.patch
Description: Binary data
v4-0008-Update-document.patch
Description: Binary data
v4-0009-Preallocate-and-initialize-more-WAL-if-wal_pmem_m.patch
Description: Binary data
