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>
