Re: Failure with 004_logrotate in prairiedog

At Sun, 18 Jul 2021 12:32:20 +0900, Michael Paquier <michael(at)paquier(dot)xyz> 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 to rotate log file
> could not read
> "/Users/buildfarm/bf-data/HEAD/pgsql.build/src/bin/pg_ctl/tmp_check/t_004_logrotate_primary_data/pgdata/current_logfiles":
> No such file or directory at t/004_logrotate.pl line 78
> ### Stopping node "primary" using mode immediate
>
> update_metainfo_datafile() creates a temporary file renamed to
> current_logfiles with rename(). It should be atomic, though this
> error points out that this is not the case? The previous steps of
> this test ensure that current_logfiles should exist.
>
> We could use some eval blocks in this area, but a non-atomic rename()
> would cause problems in more areas. Thoughts?

PostgresNode.logrotate() just invokes pg_ctl logrotate, which ends
with triggering log rotation by a signal.

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.

For non-win32 platforms, the error is identifiable by #!{ENOENT} but
I'm not sure how we can identify the error for createFile(). $!
doesn't work, and $^E returns a human-readable string in the platform
language..

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center