Re: [HACKERS] Small race in pg_xlogdump --follow

2016-09-30 Thread Magnus Hagander
On Mon, Sep 26, 2016 at 3:59 PM, Tom Lane wrote: > Magnus Hagander writes: > > Oh, right, at the very last loop. I've never seen it need more than 1 > loop > > so I didn't manage to hit that codepath :) But yeah, saving errno and > > restoring it on the other side of pg_usleep is probably a good

Re: [HACKERS] Small race in pg_xlogdump --follow

2016-09-26 Thread Tom Lane
Magnus Hagander writes: > Oh, right, at the very last loop. I've never seen it need more than 1 loop > so I didn't manage to hit that codepath :) But yeah, saving errno and > restoring it on the other side of pg_usleep is probably a good idea. Right. On a larger scale --- I'm too uncaffeinated t

Re: [HACKERS] Small race in pg_xlogdump --follow

2016-09-26 Thread Magnus Hagander
On Mon, Sep 26, 2016 at 3:44 PM, Tom Lane wrote: > Magnus Hagander writes: > > Attached patch puts a retry loop around opening the file that retries > for 5 > > seconds (which is excessive, but should be safe) in case the file is > > missing (and still fails out for other error messages of cours

Re: [HACKERS] Small race in pg_xlogdump --follow

2016-09-26 Thread Tom Lane
Magnus Hagander writes: > Attached patch puts a retry loop around opening the file that retries for 5 > seconds (which is excessive, but should be safe) in case the file is > missing (and still fails out for other error messages of course). > Comments? The patch assumes that pg_usleep won't chan

[HACKERS] Small race in pg_xlogdump --follow

2016-09-26 Thread Magnus Hagander
When using pg_xlogdump in --follow mode, there is what I believe is a small race condition when files are switched. If pg_xlogdump detects then end of one file (by looking at the record) it will immediately try to open the following file. If that file has not yet been created, it will fail with an