From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Juan José Santamaría Flecha <juanjo(dot)santamaria(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz> |
Subject: | Re: stat() vs ERROR_DELETE_PENDING, round N + 1 |
Date: | 2021-09-02 10:51:06 |
Message-ID: | CA+hUKGKvv=r-_BpPvFO4-no-Mn1WNZaFb_XCU=0+aQPDkVt5nA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Sep 2, 2021 at 10:31 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Thomas Munro <thomas(dot)munro(at)gmail(dot)com> writes:
> > A disruptive solution that works in my tests: we could reuse the
> > global barrier proposed in CF #2962. If you see EACCES, ask every
> > backend to close all vfds at their next CFI() and wait for them all to
> > finish, and then retry. If you get EACCES again it really means
> > EACCES, but you'll very probably get ENOENT.
>
> That seems quite horrid :-(. But if it works, doesn't that mean that
> somewhere we are opening a problematic file without the correct
> sharing flags?
I'm no expert, but not AFAICS. We managed to delete the file while
some other backend had it open, which FILE_SHARE_DELETE allowed. We
just can't open it or create a new file with the same name until it's
really gone (all handles closed).
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2021-09-02 11:07:10 | Re: Fix pkg-config file for static linking |
Previous Message | Peter Eisentraut | 2021-09-02 10:36:51 | Re: public schema default ACL |