Re: [BUGS] pgsql 8.0 beta1 patch for token and timezone
I have reviewed your patch. I found that the first patch was definitely needed. Your code adds escapes for single quotes in locale names placed in postgresql.conf. I also added code to escape a literal backslash as well. I re-factored your code and applied the attached patch. Your second patch to pgtz.c is not needed anymore because we have a more general solution added on September 1: /* * Localized Windows versions return localized names for the * timezone. Scan the registry to find the English name, * and then try matching against our table again. */ memset(localtzname, 0, sizeof(localtzname)); if (RegOpenKeyEx(HKEY_LOCAL_MACHINE, "SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Time Zones", 0, KEY_READ, &rootKey) != ERROR_SUCCESS) Thanks. --- Zhong Jacky wrote: > Hi pgsql-bugs, > >I'm a Chinese and I am using WinXp Chs to compile pgsql 8.0 beta 1 > in the MinGW environment. I found 2 bugs and fix them, maybe you can > merge the patch into the offical release, thanks. > >Part A) Below is the two bugs occur when we run initdb under WinXp Chs. > >1) FATAL: syntax error in file "E:/Unix/Sys/Pgsql/data/postgresql.conf" > > line 261, near token "s" > > Reason: the string 'Chinese_People's Republic of China.936' should be > 'Chinese_People\'s Republic of China.936', otherwise token mismatch. Plese > remember the regular expression like sed and awk under Unix. > > Patch: I wrote a function to detect ' in string and insert a \ symbol > >2) WARNING: could not find a match for Windows timezone "??" > > Reason: "??" is the string stands for "China Standard > Time", > which shows in Chinese language. > > Patch: use a scanzone() function to find and convert timezone to the > English string in win32_tzmap[]. I can fix only Chinese because I only have > WinXp Chs operating system, people can fix others in similar way. > >Part B) You can visit these 2 websites for more detail and get patch. >1) http://blog.csdn.net/chaoyuebetter/archive/2004/08/13/73785.aspx >2) http://www.smth.edu.cn/bbsgcon.php?board=NewSoftware&num=2548 > >Part C) The patch is based on snap0812, but can work on snap0825, etc. > > Regards, > Jacky > > _ > MSN Explorer: http://explorer.msn.com/lccn/ > > > ---(end of broadcast)--- > TIP 4: Don't 'kill -9' the postmaster > -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 Index: src/bin/initdb/initdb.c === RCS file: /cvsroot/pgsql-server/src/bin/initdb/initdb.c,v retrieving revision 1.56 diff -c -c -r1.56 initdb.c *** src/bin/initdb/initdb.c 6 Oct 2004 09:13:10 - 1.56 --- src/bin/initdb/initdb.c 7 Oct 2004 16:45:32 - *** *** 181,186 --- 181,187 static void make_template0(void); static void trapsig(int signum); static void check_ok(void); + static void escape_locale(char **locale); static bool chklocale(const char *locale); static void setlocales(void); static void usage(const char *progname); *** *** 1099,1114 snprintf(repltok, sizeof(repltok), "shared_buffers = %d", n_buffers); conflines = replace_token(conflines, "#shared_buffers = 1000", repltok); snprintf(repltok, sizeof(repltok), "lc_messages = '%s'", lc_messages); conflines = replace_token(conflines, "#lc_messages = 'C'", repltok); snprintf(repltok, sizeof(repltok), "lc_monetary = '%s'", lc_monetary); conflines = replace_token(conflines, "#lc_monetary = 'C'", repltok); snprintf(repltok, sizeof(repltok), "lc_numeric = '%s'", lc_numeric); - conflines = replace_token(conflines, "#lc_numeric = 'C'", repltok); snprintf(repltok, sizeof(repltok), "lc_time = '%s'", lc_time); conflines = replace_token(conflines, "#lc_time = 'C'", repltok); --- 1100,1119 snprintf(repltok, sizeof(repltok), "shared_buffers = %d", n_buffers); conflines = replace_token(conflines, "#shared_buffers = 1000", repltok); + + escape_locale(&lc_messages); snprintf(repltok, sizeof(repltok), "lc_messages = '%s'", lc_messages); conflines = replace_token(conflines, "#lc_messages = 'C'", repltok); + escape_locale(&lc_monetary); snprintf(repltok, sizeof(repltok), "lc_monetary = '%s'", lc_monetary); conflines = replace_token(conflines, "#lc_monetary = 'C'", replto
Re: [BUGS] pgsql 8.0 beta1 patch for token and timezone
Bruce Momjian <[EMAIL PROTECTED]> writes:
> + /*
> + * Escape any single quotes or backslashes in locale
> + */
> + static void
> + escape_locale(char **locale)
> + {
> + int len = strlen(*locale),
> + i, j;
> + char*loc_temp = xmalloc(len * 2);
> +
> + for (i = 0, j = 0; i < len; i++)
> + {
> + if ((*locale)[i] == '\'' || (*locale)[i] == '\\')
> + loc_temp[j++] = '\\';
> + loc_temp[j++] = (*locale)[i];
> + }
> + *locale = loc_temp;
> + }
Surely this is quite broken. You need to xmalloc one more byte and
add a '\0'.
regards, tom lane
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Re: [BUGS] pgsql 8.0 beta1 patch for token and timezone
OK, fixed.
---
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > + /*
> > + * Escape any single quotes or backslashes in locale
> > + */
> > + static void
> > + escape_locale(char **locale)
> > + {
> > + int len = strlen(*locale),
> > + i, j;
> > + char*loc_temp = xmalloc(len * 2);
> > +
> > + for (i = 0, j = 0; i < len; i++)
> > + {
> > + if ((*locale)[i] == '\'' || (*locale)[i] == '\\')
> > + loc_temp[j++] = '\\';
> > + loc_temp[j++] = (*locale)[i];
> > + }
> > + *locale = loc_temp;
> > + }
>
> Surely this is quite broken. You need to xmalloc one more byte and
> add a '\0'.
>
> regards, tom lane
>
> ---(end of broadcast)---
> TIP 5: Have you checked our extensive FAQ?
>
>http://www.postgresql.org/docs/faqs/FAQ.html
>
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [BUGS] BUG #1236: still in use tablespaces can be removed
Added to open items list: * Fix error message when creating objects in schema that has a dropped tablespace as its default I can confirm the bug still exists in CVS. --- Fabien COELHO wrote: > > Dear Tom, > > > > Suggested fix: create some empty file in the directory > > > if it is used by a namespace. > > > > This was discussed and rejected before --- the problem is not worth the > > amount of mechanism that would have to be added to fix it this way. > > See the pghackers archives, but I believe the main problem is that a > > namespace is not a table and so none of the mechanisms that support file > > creation/deletion will work with it. > > I just made a small suggestion on how to fix it, and I agree that it > may not be appropriate. I just seemed a simple solution wrt to how > pg decides how the tablespace may be removed. > > As for reading the pghackers history on tablespace, I guess that beta is > for testing the software and reporting issues. So I spend some time > testing new features, and if there is a problem I report it. If you thing > the problem is not worth solving, well, I've made my part by testing and > reporting it! > > >From what I've seen aboutt tablespaces, it seems to me that the > implementation is just NOT finished, whether beta freeze or not. This > means that anyone that who will use this feature in 8.0 will run into > these issues. > > Have a nice day, > > -- > Fabien Coelho - [EMAIL PROTECTED] > > ---(end of broadcast)--- > TIP 4: Don't 'kill -9' the postmaster > -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [BUGS] BUG #1238: postgres option -Q used in src/test/bench
I removed the -Q mention in the comments but Tom already fixed this in early September. --- PostgreSQL Bugs List wrote: > > The following bug has been logged online: > > Bug reference: 1238 > Logged by: A Wu > > Email address: [EMAIL PROTECTED] > > PostgreSQL version: 8.0 Beta > > Operating system: Linux 2.6.7-gentoo-r14 x86_64 > > Description:postgres option -Q used in src/test/bench > > Details: > > src/test/bench/create.sh and src/test/bench/runwisc.sh both invoke > "postgres" with a -Q option which is not supported in 8.0 Beta1. Deleting -Q > from both files allows the scripts to run to completion. > > > ---(end of broadcast)--- > TIP 6: Have you searched our list archives? > >http://archives.postgresql.org > -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[BUGS] BUG #1283: Queries slow down after restoring big db
The following bug has been logged online: Bug reference: 1283 Logged by: Fabio Fucci Email address: [EMAIL PROTECTED] PostgreSQL version: 7.3 Operating system: linux Description:Queries slow down after restoring big db Details: We dumped a database with a lot of data using command pg_dump mydb > mydb.dump Then we reimported the data in this way: 1- createdb anotherdb 2- psql anotherdb < mydb.dump After the data was restored queries(SELECT queries, with JOINs) was very very slow. We solved the problem making a separate dump for the database schema and one for the data and then reimported first the schema and then the data. ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [BUGS] BUG #1238: postgres option -Q used in src/test/bench
Bruce Momjian <[EMAIL PROTECTED]> writes: > I removed the -Q mention in the comments but Tom already fixed this in > early September. Actually, I deliberately left that comment alone, since it appeared to me to be a statement of historical fact --- ie, that *was* what they did for some now-forgotten paper --- not a recommendation of how to do things now. It's a judgment call though. regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [BUGS] Bug in PostrgeSQL 8.0beta
"Alexander Zhiltsov" <[EMAIL PROTECTED]> writes: > "Tom Lane" <[EMAIL PROTECTED]> wrote: >> I'm not convinced this is really a bug, because pg_index.indexprs is not >> an expression (it's a list of expressions) and so it's not clear that >> pg_get_expr should be expected to work on it. What result were you >> expecting to get? > Yes, probably it is not a bug, but only a difference in behavior of function > pg_get_expr in versions 7.4 and 8.0. > Server 7.4 returns readable representation of index expressions that are > combined by 'AND'. Hmm, well that wasn't really the desired behavior either, since the index expressions certainly aren't combined as though by AND. I've fixed it so that 8.0 will return the expressions comma-separated, which seems a reasonably sane behavior. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [BUGS] BUG #1283: Queries slow down after restoring big db
"PostgreSQL Bugs List" <[EMAIL PROTECTED]> writes: > We dumped a database with a lot of data using command pg_dump mydb > > mydb.dump > Then we reimported the data in this way: > 1- createdb anotherdb > 2- psql anotherdb < mydb.dump > After the data was restored queries(SELECT queries, with JOINs) was very > very slow. Did you ANALYZE after importing? regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [BUGS] BUG #1238: postgres option -Q used in src/test/bench
Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > I removed the -Q mention in the comments but Tom already fixed this in > > early September. > > Actually, I deliberately left that comment alone, since it appeared to > me to be a statement of historical fact --- ie, that *was* what they did > for some now-forgotten paper --- not a recommendation of how to do > things now. It's a judgment call though. Yea, I just remove the entire comment. It is just too long to be relevant, no? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[BUGS]
unsubscribe pgsql-bugs ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [BUGS] BUG #1254: CIDR check for no host-bit set has off-by-1 error
Nice catch. Patch attached and applied. Thanks.
We will have to mention in the release notes that this as a possible bad
data load problem from previous releases. I have already marked the
commit message accordingly.
I have also adjusted the regression tests to test for success and
failure of CIDR masks that are part of the final byte being tested.
---
PostgreSQL Bugs List wrote:
>
> The following bug has been logged online:
>
> Bug reference: 1254
> Logged by: kevin brintnall
>
> Email address: [EMAIL PROTECTED]
>
> PostgreSQL version: 7.4.5
>
> Operating system: FreeBSD 4.8-RELEASE and SunOS 5.8
>
> Description:CIDR check for no host-bit set has off-by-1 error in
> src/backend/utils/adt/network.c
>
> Details:
>
> The function addressOK() in src/backend/utils/adt/network.c
> allows some invalid values to be inserted into CIDR columns.
>
> I think this is because the author confused the Nth octet in
> an IP dotted-quad with the array offset a[N], which of course
> will produce an off-by-one error. Here is an example of some
> INSERTs that are permitted but SHOULD BE REJECTED because they
> contain 1's in the host bits:
>
> test=> INSERT INTO c (ip) VALUES ('204.248.199.199/30');
> INSERT 17160 1
> test=> INSERT INTO c (ip) VALUES ('204.248.199.199/26');
> INSERT 17161 1
> test=> INSERT INTO c (ip) VALUES ('204.248.199.199/25');
> INSERT 17162 1
>
> You can see that the INSERTs start to fail at the /24 byte
> boundary.
>
> test=> INSERT INTO c (ip) VALUES ('204.248.199.199/24');
> ERROR: invalid cidr value: "204.248.199.199/24"
> DETAIL: Value has bits set to right of mask.
> test=> INSERT INTO c (ip) VALUES ('204.248.199.199/23');
> ERROR: invalid cidr value: "204.248.199.199/23"
> DETAIL: Value has bits set to right of mask.
>
> You can see the same problem manifest at the byte boundary
> between /16 and /17. Note that NONE of these INSERTs should
> be accepted.
>
> test=> INSERT INTO c (ip) VALUES ('204.248.199.0/18');
> INSERT 17166 1
> test=> INSERT INTO c (ip) VALUES ('204.248.199.0/17');
> INSERT 17167 1
> test=> INSERT INTO c (ip) VALUES ('204.248.199.0/16');
> ERROR: invalid cidr value: "204.248.199.0/16"
> DETAIL: Value has bits set to right of mask.
> test=> INSERT INTO c (ip) VALUES ('204.248.199.0/15');
> ERROR: invalid cidr value: "204.248.199.0/15"
> DETAIL: Value has bits set to right of mask.
>
> The function uses this integer division to "round up" to
> the next byte. Here it is clear that the author was
> thinking of IP octets and not array offsets:
>
> byte = (bits + 7) / 8;
>
> Here is a table listing which byte we want to start
> comparing for various values of bits:
>
> bits=0..7 start with a[0]
> bits=8..15start with a[1]
> bits=16..23 start with a[2]
> bits=24..31 start with a[3]
>
> Since byte is used as an array offset (a[byte]), it
> is clear that that line should "round down" instead of "round up".
>
> Here is a patch listing the fix:
>
> 920c920
> < byte = (bits + 7) / 8;
> ---
> > byte = bits / 8;
>
> After applying this patch, the CIDR data type has its expected behavior,
> as we can see with the following INSERT commands:
>
> test=> INSERT INTO c (ip) VALUES ('204.248.199.199/32');
> INSERT 17168 1
> test=> INSERT INTO c (ip) VALUES ('204.248.199.199/31');
> ERROR: invalid cidr value: "204.248.199.199/31"
> DETAIL: Value has bits set to right of mask.
> test=> INSERT INTO c (ip) VALUES ('204.248.199.199/30');
> ERROR: invalid cidr value: "204.248.199.199/30"
> DETAIL: Value has bits set to right of mask.
>
> test=> INSERT INTO c (ip) VALUES ('204.248.199.199/26');
> ERROR: invalid cidr value: "204.248.199.199/26"
> DETAIL: Value has bits set to right of mask.
>
> test=> INSERT INTO c (ip) VALUES ('204.248.199.0/24');
> INSERT 17169 1
> test=> INSERT INTO c (ip) VALUES ('204.248.199.0/23');
> ERROR: invalid cidr value: "204.248.199.0/23"
> DETAIL: Value has bits set to right of mask.
> test=> INSERT INTO c (ip) VALUES ('204.248.199.0/22');
> ERROR: invalid cidr value: "204.248.199.0/22"
> DETAIL: Value has bits set to right of mask.
>
> I believe the regression tests should also be modified to
> catch errors of this type. The use of bit-boundary
> netmasks in the regression test prevented this error from being
> discovered sooner.
>
> This error has existed since the "inet" data type was
> generalized from an IPV4-only 32-bit unsigned value to a generic
> character array in revision 1.42 (24/January/2003).
>
> Please let me know if/when you decide to integrate this fix.
>
> Thanks!! I really like your product.
>
> kevin brintnall
> <[EMAIL PROTECTED]>
>
>
> ---(end of broadcast)---
> TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
>
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROT
[BUGS] PANIC: ERRORDATA_STACK_SIZE exceeded
psql -f zouxian-data-bak.sql __ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail CREATE TABLE CREATE TABLE CREATE TABLE CREATE TABLE CREATE TABLE CREATE TABLE CREATE TABLE CREATE TABLE CREATE TABLE CREATE TABLE CREATE TABLE CREATE TABLE CREATE TABLE CREATE TABLE CREATE TABLE CREATE TABLE CREATE TABLE SET SET psql:zouxian-data-bak:243910: PANIC: ERRORDATA_STACK_SIZE exceeded psql:zouxian-data-bak:243921: server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. psql:zouxian-data-bak:243921: connection to server was lost -bash-2.05b$ psql:zouxian-data-bak:243910: PANIC: ERRORDATA_STACK_SIZE exceeded psql:zouxian-data-bak:243921: server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. psql:zouxian-data-bak:243921: connection to server was lost LOG: server process (PID 29682) was terminated by signal 6 LOG: terminating any other active server processes LOG: all server processes terminated; reinitializing ---(end of broadcast)--- TIP 8: explain analyze is your friend
