pg_upgrade code questions - Mailing list pgsql-hackers

From Takahiro Itagaki
Subject pg_upgrade code questions
Date
Msg-id 20100513151303.A1D8.52131E4D@oss.ntt.co.jp
Whole thread Raw
Responses Re: pg_upgrade code questions
Re: pg_upgrade code questions
List pgsql-hackers
I read pg_upgrade code glance over, and found 4 issues in it.
Are there any issues to be fixed before 9.0 release?
   1. NAMEDATASIZE   2. extern PGDLLIMPORT   3. pathSeparator   4. EDB_NATIVE_LANG

==== 1. NAMEDATASIZE ====
pg_upgrade has the following definition, but should it be just NAMEDATALEN?
   /* Allocate for null byte */   #define NAMEDATASIZE        (NAMEDATALEN + 1)

Table names should be in NAMEDATELEN - 1 bytes. At least 64th bytes in 
"name" data is always '\0'.
   =# CREATE TABLE "1234567890...(total 70 chars)...1234567890" (i int);   NOTICE:  identifier "123...890" will be
truncatedto "123...0123"
 

==== 2. extern PGDLLIMPORT ====
pg_upgrade has own definitions of   extern PGDLLIMPORT Oid binary_upgrade_next_xxx
in pg_upgrade_sysoids.c. But those variables are not declared as
PGDLLIMPORT in the core. Can we access unexported variables here?

==== 3. pathSeparator ====
Path separator for Windows is not only \ but also /. The current code
ignores /. Also, it might not work if the path string including multi-byte
characters that have \ (0x5c) in the second byte.

==== 4. EDB_NATIVE_LANG ====
Of course it is commented out with #ifdef, but do we have codes
for EDB in core?

Regards,
---
Takahiro Itagaki
NTT Open Source Software Center



pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: recovery getting interrupted is not so unusual as it used to be
Next
From: Koichi Suzuki
Date:
Subject: Re: Re: [ANNOUNCE] Bug-fix and new feature of pg_lesslog is released