Re: More time spending with "delete pending"
От | Alexander Lakhin |
---|---|
Тема | Re: More time spending with "delete pending" |
Дата | |
Msg-id | 979f4ee6-9960-e37f-f3ee-f458e87777b0@gmail.com обсуждение исходный текст |
Ответ на | Re: More time spending with "delete pending" (Justin Pryzby <pryzby@telsasoft.com>) |
Ответы |
Re: More time spending with "delete pending"
Re: More time spending with "delete pending" |
Список | pgsql-hackers |
15.11.2020 04:11, Justin Pryzby wrote: > On Sat, Nov 14, 2020 at 01:00:00PM +0300, Alexander Lakhin wrote: >> As noted in [1], a sensible solution would be putting the same "retry on >> ERROR_ACCESS_DENIED" action in a wrapper for stat(). >> And bed90759f brought in master the _pgstat64() function, where such >> error handling should be placed. >> So please look at the patch (based on the previous one made to fix >> bug#16161), that makes the attached test pass. > Your patch introduces a "loops", but doesn't use it to escape the loop. Indeed, this is my mistake. Please look at the corrected patch (now that code corresponds to the pgwin32_open() as intended). And it rises another question, what if pg_ls_dir_files() is called for a directory where hundreds or thousands of files are really inaccessible due to restrictions? I mean that using CreateFile() in the modified stat() implementation can be rather expensive for an arbitrary file (and worse yet, for many files). On the positive side, for now pg_ls_dir_files() is called only from pg_ls_logdir, pg_ls_waldir, pg_ls_tmpdir, pg_ls_archive_statusdir, where having a bunch of files that are inaccessible for the postgres user is not expected anyway. But probably getting directory contents with correct file sizes (>4GB) in pg_ls_dir_files() can be implemented without calling CreateFile()/stat() at all (as ProcMon shows, the "dir" command doesn't call CreateFile() (or any other system function) for each file in the target directory). Best regards, Alexander
Вложения
В списке pgsql-hackers по дате отправления: