Re: Regression test PANICs with master-standby setup on same machine

From: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
To: kuntalghosh(dot)2007(at)gmail(dot)com
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Regression test PANICs with master-standby setup on same machine
Date: 2019-04-22 12:36:41
Message-ID: 20190422.213641.218914460.horiguchi.kyotaro@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello.

At Mon, 22 Apr 2019 15:52:59 +0530, Kuntal Ghosh <kuntalghosh(dot)2007(at)gmail(dot)com> wrote in <CAGz5QC+j1BDq7onp6H8Cye-ahD2zS1dLttp-dEuEoZStEjxq5Q(at)mail(dot)gmail(dot)com>
> Hello hackers,
>
> With a master-standby setup configured on the same machine, I'm
> getting a panic in tablespace test while running make installcheck.
>
> 1. CREATE TABLESPACE regress_tblspacewith LOCATION 'blah';
> 2. DROP TABLESPACE regress_tblspacewith;
> 3. CREATE TABLESPACE regress_tblspace LOCATION 'blah';
> -- do some operations in this tablespace
> 4. DROP TABLESPACE regress_tblspace;
>
> The master panics at the last statement when standby has completed
> applying the WAL up to step 2 but hasn't started step 3.
> PANIC: could not fsync file
> "pg_tblspc/16387/PG_12_201904072/16384/16446": No such file or
> directory
>
> The reason is both the tablespace points to the same location. When
> master tries to delete the new tablespace (and requests a checkpoint),
> the corresponding folder is already deleted by the standby while
> applying WAL to delete the old tablespace. I'm able to reproduce the
> issue with the attached script.
>
> sh standby-server-setup.sh
> make installcheck
>
> I accept that configuring master-standby on the same machine for this
> test is not okay. But, can we avoid the PANIC somehow? Or, is this
> intentional and I should not include testtablespace in this case?

If you don't have a problem using TAP test suite, tablespace is
allowed with a bit restricted steps using the first patch in my
just posted patchset[1]. This will work for you if you are okay
with creating a standby after creating a tablespace. See the
second patch in the patchset.

If you stick on shell script, the following steps allow tablespaces.

1. Create tablespace directories for both master and standby.
2. Create a master then start.
3. Create tablespaces on the master.
4. Create a standby using pg_basebackup --tablespace_mapping=<mstdir>=<sbydir>
5. Start the standby.

[1] https://www.postgresql.org/message-id/20190422.211933.156769089.horiguchi.kyotaro@lab.ntt.co.jp

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Etsuro Fujita 2019-04-22 12:45:36 Re: pgsql: Allow insert and update tuple routing and COPY for foreign table
Previous Message Kyotaro HORIGUCHI 2019-04-22 12:19:33 Re: standby recovery fails (tablespace related) (tentative patch and discussion)