Thread: Is this a bug in pg_current_logfile() on Windows?
Hello,
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.
This does not happen when running Postgres on Linux.
Is this intended for some strange reason?
Or a bug or a technical limitation?
Regards
Thomas
On 7/8/20 6:05 AM, Thomas Kellerer wrote: > Hello, > > 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. > > This does not happen when running Postgres on Linux. > > Is this intended for some strange reason? > Or a bug or a technical limitation? I'm guessing the difference between Unix line ending: \n and Windows: \r\n > > Regards > Thomas > > -- Adrian Klaver adrian.klaver@aklaver.com
On 7/8/20 6:45 AM, Adrian Klaver wrote:
> On 7/8/20 6:05 AM, Thomas Kellerer wrote:
>> Hello,
>>
>> 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.
>>
>> This does not happen when running Postgres on Linux.
>>
>> Is this intended for some strange reason?
>> Or a bug or a technical limitation?
>
> I'm guessing the difference between Unix line ending:
>
> \n
>
> and Windows:
>
> \r\n
>
From source(backend/utils/adt/misc.c):
nlpos = strchr(log_filepath, '\n');
if (nlpos == NULL)
{
/* Uh oh. No newline found, so file content is corrupted. */
elog(ERROR,
"missing newline character in \"%s\"",
LOG_METAINFO_DATAFILE);
break;
}
*nlpos = '\0';
if (logfmt == NULL || strcmp(logfmt, log_format) == 0)
{
FreeFile(fd);
PG_RETURN_TEXT_P(cstring_to_text(log_filepath));
}
>>
>> Regards
>> Thomas
>>
>>
>
>
--
Adrian Klaver
adrian.klaver@aklaver.com
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
Tom Lane schrieb am 08.07.2020 um 18:41: > 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? That's the build from EnterpriseDB https://www.enterprisedb.com/download-postgresql-binaries