Re: [BUGS] Checkpoints occur too frequently
Tom Lane <[EMAIL PROTECTED]> writes: > Simon Riggs <[EMAIL PROTECTED]> writes: >> I'd say no code changes for 8.0, now we know what's causing it. A doc >> patch to show the limit is probably just going to annoy the translators >> at this stage also. > We could adjust guc.c to limit checkpoint_segments to the range 1..255 > without having to touch any translatable strings. This isn't a > necessary change but it seems harmless ... any objections? Or we could just fix it. After thinking a bit more, I realized that it's not hard to push the forced-checkpoint boundary out to 2^32 segments instead of 255. That should be enough to still any complaints. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[BUGS] timestamp arithmetic
Note the queries below generate the same result regardless of the timezone input: % env | grep TZ PGTZ=CST6CDT TZ=CST6CDT % psql -t -c "select version()" PostgreSQL 8.0.0beta3 on i686-pc-linux-gnu, compiled by GCC 2.96 % psql -t -c "select '1970-01-01 00:00:00+09'::timestamp + '1089352800 seconds'::interval" 2004-07-09 06:00:00 % psql -t -c "select '1970-01-01 00:00:00+03'::timestamp + '1089352800 seconds'::interval" 2004-07-09 06:00:00 % psql -t -c "select '1970-01-01 00:00:00+01'::timestamp + '1089352800 seconds'::interval" 2004-07-09 06:00:00 Ed ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [BUGS] timestamp arithmetic
"Ed L." <[EMAIL PROTECTED]> writes: > Note the queries below generate the same result regardless of the timezone > input: This isn't a bug. Per documentation: : For timestamp [without time zone], any explicit time zone specified in : the input is silently ignored. That is, the resulting date/time value is : derived from the explicit date/time fields in the input value, and is : not adjusted for time zone. You want to use timestamp with time zone (timestamptz), I think. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[BUGS] BUG #1350: Backslash ecape charcter violates ISO/ANSI spec and is hazardous
The following bug has been logged online: Bug reference: 1350 Logged by: Ken Johanson Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0 Beta Operating system: Any Description:Backslash ecape charcter violates ISO/ANSI spec and is hazardous Details: I can't find any option to run the server in a more standard mode for string escaping rules, of only needing to escape single quotes. The current backslash-escape behavior is a huge problem for SQL statement portability, a spec violation, and blindsides developers coming from Oracle, Sybase, MS, etc. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] BUG #1350: Backslash ecape charcter violates ISO/ANSI spec
PostgreSQL Bugs List wrote: > Description:Backslash ecape charcter violates ISO/ANSI spec and is > hazardous > > Details: > > I can't find any option to run the server in a more standard mode for string > escaping rules, of only needing to escape single quotes. The current > backslash-escape behavior is a huge problem for SQL statement portability, a > spec violation, and blindsides developers coming from Oracle, Sybase, MS, > etc. We have a TODO item: * Allow backslash handling in quoted strings to be disabled for portability The use of C-style backslashes (.e.g. \n, \r) in quoted strings is not SQL-spec compliant, so allow such handling to be disabled. Unfortunately that's all we have. :-) -- 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 4: Don't 'kill -9' the postmaster
[BUGS] BUG #1349: Gap in documentation - pg_dump
The following bug has been logged online: Bug reference: 1349 Logged by: PiotrL Email address: [EMAIL PROTECTED] PostgreSQL version: 7.4.6 Operating system: Windows Description:Gap in documentation - pg_dump Details: I'm sorry, but I didn't found a better place to report that: There is no information how to specify user's password in pg_dump documentation. I have spent half of day searching for that (pg_hba.conf was not working for me) and the answer is very simple: You can use SET variables for that: PGUSER=web-user PGPASSWORD=secret Please include that in pg_dump documentation. Regards, Piotr ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [BUGS] BUG #1349: Gap in documentation - pg_dump
On Thu, Dec 16, 2004 at 08:16:56 +, PostgreSQL Bugs List <[EMAIL PROTECTED]> wrote: > > I'm sorry, but I didn't found a better place to report that: > > There is no information how to specify user's password in pg_dump > documentation. I have spent half of day searching for that (pg_hba.conf was > not working for me) and the answer is very simple: > > You can use SET variables for that: > > PGUSER=web-user > PGPASSWORD=secret > > Please include that in pg_dump documentation. You don't want to do that; on many systems the contents of environment variables are visible to other processes. You can keep a password in ~/.pgpass and that will work for more than just pg_dump. If the batch scripts are running on the same machine as the server, consider using ident authentication. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] BUG #1349: Gap in documentation - pg_dump
On Thu, Dec 16, 2004 at 20:21:48 +0100, Piotr Likus <[EMAIL PROTECTED]> wrote: > > Yes, maybe it is insecure, but sometimes "quick and dirty" solutions > are better than no solution at all. > After all you can add "not recommended" note to this tip. The official documentation isn't likely to be changed to instruct people how to incorrectly set up their system. It may be that there is a deficiency in the pg_dump documentation if you are expected to know something from another part of the manual that it may not be obvious that you should know. In that case the answer is to refer to the other section or to include enough information to avoid needing to refer to the other section.` ---(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
