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.menjo@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.menjo@gmail.com>
--
Takashi Menjo <takashi.menjo@gmail.com>
