Hi,
On 2019-04-22 15:52:59 +0530, Kuntal Ghosh wrote:
> 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?
FWIW, I think the right fix for this is to simply drop the requirement
that tablespace paths need to be absolute. It's not buying us anything,
it's just making things more complicated. We should just do a simple
check against the tablespace being inside PGDATA, and leave it at
that. Yes, that can be tricked, but so can the current system.
That'd make both regression tests easier, as well as operations.
Greetings,
Andres Freund
