At Mon, 19 Jul 2021 10:23:46 -0400, Tom Lane wrote in
> Michael Paquier writes:
> > On Mon, Jul 19, 2021 at 04:15:36PM +0900, Kyotaro Horiguchi wrote:
> >> When rotation happens, the metainfo file is once removed then
> >> created. If slurp_file in the metafile-checking loop hits the gap, the
>
Michael Paquier writes:
> On Mon, Jul 19, 2021 at 04:15:36PM +0900, Kyotaro Horiguchi wrote:
>> When rotation happens, the metainfo file is once removed then
>> created. If slurp_file in the metafile-checking loop hits the gap, the
>> slurp_file fails with ENOENT.
> I can read the following code,
Kyotaro Horiguchi writes:
> When rotation happens, the metainfo file is once removed then
> created. If slurp_file in the metafile-checking loop hits the gap, the
> slurp_file fails with ENOENT.
Oh! Yeah, that's dumb, we should fix it to use rename(). Can't blame
platform's rename() if it's not
On Mon, Jul 19, 2021 at 04:15:36PM +0900, Kyotaro Horiguchi wrote:
> When rotation happens, the metainfo file is once removed then
> created. If slurp_file in the metafile-checking loop hits the gap, the
> slurp_file fails with ENOENT.
I can read the following code, as of update_metainfo_datafile(
At Sun, 18 Jul 2021 12:32:20 +0900, Michael Paquier wrote
in
> Hi all,
>
> prairiedog has failed in a way that seems a bit obscure to me:
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=prairiedog&dt=2021-07-18%2000%3A23%3A29
>
> Here are the details of the failure:
> server signaled
Michael Paquier writes:
> On Sun, Jul 18, 2021 at 01:42:18AM -0400, Tom Lane wrote:
>> Awhile back we discovered that old macOS versions have non-atomic rename
>> [1]. I eventually shut down dromedary because that was causing failures
>> often enough to be annoying. I'd not seen such a failure b
On Sun, Jul 18, 2021 at 01:42:18AM -0400, Tom Lane wrote:
> Awhile back we discovered that old macOS versions have non-atomic rename
> [1]. I eventually shut down dromedary because that was causing failures
> often enough to be annoying. I'd not seen such a failure before on
> prairiedog, but it
Michael Paquier writes:
> prairiedog has failed in a way that seems a bit obscure to me:
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=prairiedog&dt=2021-07-18%2000%3A23%3A29
> ...
> We could use some eval blocks in this area, but a non-atomic rename()
> would cause problems in more ar
