Heikki Linnakangas writes:
> On 06/09/2020 18:06, Tom Lane wrote:
>> I propose to remove the lstat() in the back branches, but not touch
>> HEAD so as not to cause extra merge effort for your patch.
> Thanks! Feel free to push it to HEAD, too, the merge conflict will be
> trivial to resolve.
OK
On 06/09/2020 18:06, Tom Lane wrote:
Heikki Linnakangas writes:
On 05/09/2020 21:18, Tom Lane wrote:
Or actually, maybe we should just drop the lstat call altogether?
Agreed, the lstat() doesn't do anything interesting.
This is refactored away by the patches discussed at
https://www.postgre
Heikki Linnakangas writes:
> On 05/09/2020 21:18, Tom Lane wrote:
>> Or actually, maybe we should just drop the lstat call altogether?
> Agreed, the lstat() doesn't do anything interesting.
> This is refactored away by the patches discussed at
> https://www.postgresql.org/message-id/f155aab5-132
On 05/09/2020 21:18, Tom Lane wrote:
I wrote:
It looks to me like we could replace "exists = false" with "return",
rather than uselessly constructing a FILE_ACTION_REMOVE entry for
a file we've already proven is not there.
Or actually, maybe we should just drop the lstat call altogether?
AFAIC
I wrote:
> It looks to me like we could replace "exists = false" with "return",
> rather than uselessly constructing a FILE_ACTION_REMOVE entry for
> a file we've already proven is not there.
Or actually, maybe we should just drop the lstat call altogether?
AFAICS it's 99.99% redundant with the ls
scan-build complains that "exists = false" is a dead store,
which it is:
process_target_file(const char *path, file_type_t type, size_t oldsize,
const char *link_target)
{
boolexists;
...
if (lstat(localpath, &statbuf) < 0)
{
if (errno != ENOENT
