Re: stat() vs ERROR_DELETE_PENDING, round N + 1
От | Thomas Munro |
---|---|
Тема | Re: stat() vs ERROR_DELETE_PENDING, round N + 1 |
Дата | |
Msg-id | CA+hUKGKvv=r-_BpPvFO4-no-Mn1WNZaFb_XCU=0+aQPDkVt5nA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: stat() vs ERROR_DELETE_PENDING, round N + 1 (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: stat() vs ERROR_DELETE_PENDING, round N + 1
|
Список | pgsql-hackers |
On Thu, Sep 2, 2021 at 10:31 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > Thomas Munro <thomas.munro@gmail.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).
В списке pgsql-hackers по дате отправления: