Horton

Re: Is this a bug in pg_current_logfile() on Windows?

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Thomas Kellerer <shammat@gmx.net>
Cc: pgsql-general@lists.postgresql.org
Date: 2020-07-08T16:41:36Z
Lists: pgsql-hackers, pgsql-general 
Thomas Kellerer <shammat@gmx.net> writes:
> I noticed the following strage output when running Postgres 12.3 (not psql) on Windows

>     postgres=# select pg_current_logfile();
>              pg_current_logfile
>     ------------------------------------
>      pg_log/postgresql-2020-07-08.log\r
>     (1 row)

> Note the "\r" at the end of the file name.

Yeah, that seems like a bug.  I think the reason is that syslogger.c
does this when writing the log metafile:

	fh = fopen(LOG_METAINFO_DATAFILE_TMP, "w");
...
#ifdef WIN32
		/* use CRLF line endings on Windows */
		_setmode(_fileno(fh), _O_TEXT);
#endif

while misc.c only does this when reading the file:

	fd = AllocateFile(LOG_METAINFO_DATAFILE, "r");

Somehow, the reading file is being left in binary mode and thus it's
failing to convert \r\n back to plain \n.

Now the weird thing about that is I'd have expected "r" and "w" modes
to imply Windows text mode already, so that I'd have figured that
_setmode call to be a useless no-op.  Apparently on some Windows libc
implementations, it's not.  How was your installation built exactly?

			regards, tom lane

Commits

  1. Tighten up Windows CRLF conversion in our TAP test scripts.

  2. Fix pg_current_logfile() to not emit a carriage return on Windows.

  3. Further tighten Windows CRLF conversion in our TAP test scripts.

  4. Add test coverage for pg_current_logfile() function.

  5. Fix failures to ignore \r when reading Windows-style newlines.

  6. Fix TAP infrastructure to support Mingw better