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
