Hello hackers, 31.03.2020 19:41, Tom Lane wrote: > Justin Pryzby <pry...@telsasoft.com> writes: >> I suggest to leave stat() alone in your patch for stable releases. I think >> it's okay if we change behavior so that a broken symlink is skipped instead >> of >> erroring (as a side effect of skipping ENOENT with stat()). But not okay if >> we >> change pg_ls_logdir() to hide symlinks in back braches. > Meh. I'm not really convinced, but in the absence of anyone expressing > support for my position, I'll do it that way. I don't think it's worth > doing both a stat and lstat to tell the difference between file-is-gone > and file-is-a-broken-symlink. As we've discovered in Bug #[16161], stat() for "concurrently-deleted file" can also return ERROR_ACCESS_DENIED on Windows. It seems that pg_upgradeCheck failures seen on https://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=fairywren&br=REL_13_STABLE caused by the same issue. Shouldn't pg_ls_dir_files() retry stat() on ERROR_ACCESS_DENIED just like the pgwin32_open() does to ignore files in "delete pending" state?
[16161] https://www.postgresql.org/message-id/16161-7a985d2f1bbe8f71%40postgresql.org Best regards, Alexander
