Re: Don't choke on files that are removed while pg_rewind runs.

> On 13 Jul 2020, at 09:56, Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> On Mon, Jul 13, 2020 at 03:59:56PM +0900, Masahiko Sawada wrote:
>> On Mon, 13 Jul 2020 at 15:34, Daniel Gustafsson <daniel(at)yesql(dot)se> wrote:
>>> Yeah, I agree with that, seems like the call should've been PQgetisnull(res, i, 1);
>>> to match the loop.
>>
>> +1
>
> Good catch, Justin. There is a second thing here. The second column
> matches with the file size, so if its value is NULL then atol() would
> just crash first.

Does it? PGgetvalue will return an empty string and not NULL, so atol will
convert that to zero wont it? It can be argued whether zero is the right size
for a missing file, but it shouldn't crash at least.

> I think that it would be more simple to first check
> if the file size is NULL (isdir and link_target would be also NULL,
> but just checking for the file size is fine), and then assign the
> result values, like in the attached. Any thoughts?

It does convey the meaning of code to do it after, since the data isn't useful
in case the filesize is zero, but I don't have strong feelings for/against.
Question is, rather than discard rows pulled from the server, should the query
be tweaked to not include it in the first place instead?

cheers ./daniel