| From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
|---|---|
| To: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Cc: | Juan José Santamaría Flecha <juanjo(dot)santamaria(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Michael Paquier <michael(at)paquier(dot)xyz> |
| Subject: | Re: stat() vs ERROR_DELETE_PENDING, round N + 1 |
| Date: | 2021-09-02 10:28:09 |
| Message-ID: | CA+hUKG+PUp1xY+-XaTi_pD=7wgOry3Q4DNH9LDr+7g-haPcD1A@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Sep 2, 2021 at 10:10 AM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> Perhaps we need some combination of the old way (that apparently knew
> how to detect pending deletes) and the new way (that knows about large
> files)?
I tried that, but as far as I can tell, the old approach didn't really
work either :-(
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.
The cheapest solution would be to assume EACCES really means ENOENT,
but that seems unacceptably incorrect.
I suspect it might be possible to use underdocumented/unstable NtXXX()
interfaces to get at the information, but I don't know much about
that.
Is there another way that is cheap, correct and documented?
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2021-09-02 10:31:51 | Re: stat() vs ERROR_DELETE_PENDING, round N + 1 |
| Previous Message | kuroda.hayato@fujitsu.com | 2021-09-02 09:27:09 | RE: Allow escape in application_name (was: [postgres_fdw] add local pid to fallback_application_name) |