Hello hackers,
31.03.2020 19:41, Tom Lane wrote:
> Justin Pryzby <pryzby@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