On Wed, 20 Nov 2019 at 19:24, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > > On 2019-Nov-20, Juan José Santamaría Flecha wrote: > > > I was not able to reproduce the Permission denied error with current HEAD, > > until I opened another CMD inside the "pg_replslot/regression_slot" folder. > > This will be problematic, is the deletion of the folder actually needed? > > Yes :-( The code assumes that if the directory is there, then it's > valid. Trying to remove that assumption is probably a more invasive > fix. > > I think ReplicationSlotDropAcquired is too pessimistic (no recourse if > the rename fails) and too optimistic (this will almost never happen). > We could change it so that the rename is retried a few times, and avoid > the failure. (Naturally, the rmtree should also be retried.) The code > seems written with the POSIX semantics in mind, but it seems easy to > improve.
Just to be clear, there are two issues being discussed here : 1. Issue with the patch, where pg_replslot/slotname/xid-*.spill files can't be removed because the same backend process has left these files opened because of an abort. This is happening despite the file being opened using FILE_SHARE_DELETE flag. I am going to investigate (possibly the flag is not applicable in case a single process is involved) 2. This existing issue where pg_replslot/slotname directory removal will fail if someone else is accessing this directory. This has nothing to do with the patch. -- Thanks, -Amit Khandekar EnterpriseDB Corporation The Postgres Database Company
