Re: Race in "tablespace" test on Windows - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Race in "tablespace" test on Windows
Date
Msg-id CAA4eK1Lov-MyKvaRSqYGLm_Vop2UFZQ_hQ5eo4vjYHg6UyjvgQ@mail.gmail.com
Whole thread Raw
In response to Re: Race in "tablespace" test on Windows  (Noah Misch <noah@leadboat.com>)
List pgsql-hackers
On Thu, Nov 13, 2014 at 8:46 AM, Noah Misch <noah@leadboat.com> wrote:
>
> On Tue, Nov 11, 2014 at 10:21:26AM +0530, Amit Kapila wrote:
> > On Sat, Nov 8, 2014 at 10:34 AM, Noah Misch <noah@leadboat.com> wrote:
> > > Here is a briefer command sequence exhibiting the same problem:
> > >
> > > To make this work as well on Windows as it does elsewhere, DROP TABLESPACE
> > > would need to wait for other backends to close relevant unlinked files.
> > > Perhaps implement "wait_unlinked_files(const char *dirname)" to poll
> > unlinked,
> > > open files until they disappear.  (An attempt to open an unlinked file
> > reports
> > > ERROR_ACCESS_DENIED.  It might be tricky to reliably distinguish this
> > cause
> > > from other causes of that error, but it should be possible.)
> >
> > I think the proposed mechanism can work but the wait can be very long
> > (untill the backend holding descriptor executes another command).
>
> The DROP TABLESPACE could send a catchup interrupt.
>

Yeah, that can work.

> > Can we think of some other solution like in Drop Tablespace instead of
> > checking if directory is empty, check if there is no object that belongs
> > to database/cluster, then allow to forcibly delete that directory someway.
>
> I'm not aware of a way to forcibly delete the directory.  One could rename
> files to the tablespace top-level directory just before unlinking them.  Since
> DROP TABLESPACE never removes that directory, their continued presence there
> would not pose a problem.  (Compare use of the rename-before-unlink trick in
> RemoveOldXlogFiles().)  That adds the overhead of an additional system call to
> every unlink, which might be acceptable.  It may be possible to rename after
> unlink, as-needed in DROP TABLESPACE.
>

Right.  I think we can discuss further about which approach is better,
once someone decides to work on this issue.


With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: tracking commit timestamps
Next
From: Michael Paquier
Date:
Subject: Re: tracking commit timestamps