Re: Map WAL segment files on PMEM as WAL buffers

From: Takashi Menjo <takashi(dot)menjo(at)gmail(dot)com>
To: Justin Pryzby <pryzby(at)telsasoft(dot)com>
Cc: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)fujitsu(dot)com>, "Deng, Gang" <gang(dot)deng(at)intel(dot)com>, Takashi Menjo <takashi(dot)menjou(dot)vg(at)hco(dot)ntt(dot)co(dot)jp>, Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, Daniel Gustafsson <daniel(at)yesql(dot)se>
Subject: Re: Map WAL segment files on PMEM as WAL buffers
Date: 2022-01-18 10:58:35
Message-ID: CAOwnP3MKmca24HVVkmw0KL6KR8cXLk14C=-UE3YejbjS08b6qQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Justin,

Thanks for your help. I'm making an additional patch for Cirrus CI.

I'm also trying to reproduce the "make check-world" error you
reported, on my Linux environment that has neither a real PMem nor an
emulated one, with PMEM_IS_PMEM_FORCE=1. I'll keep you updated.

Regards,
Takashi

On Mon, Jan 17, 2022 at 4:34 PM Justin Pryzby <pryzby(at)telsasoft(dot)com> wrote:
>
> On Thu, Jan 06, 2022 at 10:43:37PM -0600, Justin Pryzby wrote:
> > On Fri, Jan 07, 2022 at 12:50:01PM +0900, Takashi Menjo wrote:
> > > > But in this case it really doesn't work :(
> > > >
> > > > running bootstrap script ... 2022-01-05 23:17:30.244 CST [12088] FATAL: file not on PMEM: path "pg_wal/000000010000000000000001"
> > >
> > > Do you have a real PMEM device such as NVDIMM-N or Intel Optane PMem?
> >
> > No - the point is that we'd like to have a way to exercise this patch on the
> > cfbot. Particularly the new code introduced by this patch, not just the
> > --without-pmem case...
> ..
> > I think you should add a patch which does what Thomas suggested: 1) add to
> > ./.cirrus.yaml installation of the libpmem package for debian/bsd/mac/windows;
> > 2) add setenv to main(), as above; 3) change configure.ac and guc.c to default
> > to --with-libpmem and wal_pmem_map=on. This should be the last patch, for
> > cfbot only, not meant to be merged.
>
> I was able to get the cirrus CI to compile on linux and bsd with the below
> changes. I don't know if there's an easy package installation for mac OSX. I
> think it's okay if mac CI doesn't use --enable-pmem for now.
>
> > You can test that the package installation part works before mailing patches to
> > the list with the instructions here:
> >
> > src/tools/ci/README:
> > Enabling cirrus-ci in a github repository..
>
> I ran the CI under my own github account.
> Linux crashes in the recovery check.
> And freebsd has been stuck for 45min.
>
> I'm not sure, but maybe those are legimate consequence of using
> PMEM_IS_PMEM_FORCE (?) If so, maybe the recovery check would need to be
> disabled for this patch to run on CI... Or maybe my suggestion to enable it by
> default for CI doesn't work for this patch. It would need to be specially
> tested with real hardware.
>
> https://cirrus-ci.com/task/6245151591890944
>
> https://cirrus-ci.com/task/6162551485497344?logs=test_world#L3941
> #2 0x000055ff43c6edad in ExceptionalCondition (conditionName=0x55ff43d18108 "!XLogRecPtrIsInvalid(missingContrecPtr)", errorType=0x55ff43d151c4 "FailedAssertion", fileName=0x55ff43d151bd "xlog.c", lineNumber=8297) at assert.c:69
>
> commit 15533794e465a381eb23634d67700afa809a0210
> Author: Justin Pryzby <pryzbyj(at)telsasoft(dot)com>
> Date: Thu Jan 6 22:53:28 2022 -0600
>
> tmp: enable pmem by default, for CI
>
> diff --git a/.cirrus.yml b/.cirrus.yml
> index 677bdf0e65e..0cb961c8103 100644
> --- a/.cirrus.yml
> +++ b/.cirrus.yml
> @@ -81,6 +81,7 @@ task:
> mkdir -m 770 /tmp/cores
> chown root:postgres /tmp/cores
> sysctl kern.corefile='/tmp/cores/%N.%P.core'
> + pkg install -y devel/pmdk
>
> # NB: Intentionally build without --with-llvm. The freebsd image size is
> # already large enough to make VM startup slow, and even without llvm
> @@ -99,6 +100,7 @@ task:
> --with-lz4 \
> --with-pam \
> --with-perl \
> + --with-libpmem \
> --with-python \
> --with-ssl=openssl \
> --with-tcl --with-tclconfig=/usr/local/lib/tcl8.6/ \
> @@ -138,6 +140,7 @@ LINUX_CONFIGURE_FEATURES: &LINUX_CONFIGURE_FEATURES >-
> --with-lz4
> --with-pam
> --with-perl
> + --with-libpmem
> --with-python
> --with-selinux
> --with-ssl=openssl
> @@ -188,6 +191,9 @@ task:
> mkdir -m 770 /tmp/cores
> chown root:postgres /tmp/cores
> sysctl kernel.core_pattern='/tmp/cores/%e-%s-%p.core'
> + echo 'deb http://deb.debian.org/debian bullseye universe' >>/etc/apt/sources.list
> + apt-get update
> + apt-get -y install libpmem-dev
>
> configure_script: |
> su postgres <<-EOF
> @@ -267,6 +273,7 @@ task:
> make \
> openldap \
> openssl \
> + pmem \
> python \
> tcl-tk
>
> @@ -301,6 +308,7 @@ task:
> --with-libxslt \
> --with-lz4 \
> --with-perl \
> + --with-libpmem \
> --with-python \
> --with-ssl=openssl \
> --with-tcl --with-tclconfig=${brewpath}/opt/tcl-tk/lib/ \
> diff --git a/src/backend/main/main.c b/src/backend/main/main.c
> index 9124060bde7..b814269675d 100644
> --- a/src/backend/main/main.c
> +++ b/src/backend/main/main.c
> @@ -69,6 +69,7 @@ main(int argc, char *argv[])
> #endif
>
> progname = get_progname(argv[0]);
> + setenv("PMEM_IS_PMEM_FORCE", "1", 0);
>
> /*
> * Platform-specific startup hacks
> diff --git a/src/backend/utils/misc/guc.c b/src/backend/utils/misc/guc.c
> index ffc55f33e86..32d650cb9b2 100644
> --- a/src/backend/utils/misc/guc.c
> +++ b/src/backend/utils/misc/guc.c
> @@ -1354,7 +1354,7 @@ static struct config_bool ConfigureNamesBool[] =
> "traditional volatile ones."),
> },
> &wal_pmem_map,
> - false,
> + true,
> NULL, NULL, NULL
> },
> #endif

--
Takashi Menjo <takashi(dot)menjo(at)gmail(dot)com>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tatsuro Yamada 2022-01-18 11:31:30 Re: Showing applied extended statistics in explain
Previous Message Peter Eisentraut 2022-01-18 10:38:38 Re: support for MERGE