[BUGS] BUG #4689: Expanding the length of a VARCHAR column should not induce a table rewrite

2009-03-04 Thread
The following bug has been logged online: Bug reference: 4689 Logged by: Email address: xuan--2009.03--submitbug--support--postgresql@baldauf.org PostgreSQL version: 8.3.5 Operating system: Linux 2.6.18-6-amd64 Description:Expanding the length of a VARCHAR column

Re: [BUGS] BUG #4689: Expanding the length of a VARCHAR column should not induce a table rewrite

2009-03-04 Thread Heikki Linnakangas
xuan--2009.03--submitbug--support--postgresql@baldauf.org wrote: When executing "ALTER TABLE sometable ALTER COLUMN somecolumn TYPE VARCHAR(7)", the whole table is re-written, and this rewrite takes many hours. During these hours, all writers on this table stall, making the database effective

[BUGS] BUG #4690: an select query is not using the index

2009-03-04 Thread vikas
The following bug has been logged online: Bug reference: 4690 Logged by: vikas Email address: vikas.du...@newgen.co.in PostgreSQL version: PostgreSQL 7.3 Operating system: i686-pc-linux-gnu Description:an select query is not using the index Details: hi there is a t

Re: [BUGS] BUG #4689: Expanding the length of a VARCHAR column should not induce a table rewrite

2009-03-04 Thread Peter Eisentraut
Heikki Linnakangas wrote: xuan--2009.03--submitbug--support--postgresql@baldauf.org wrote: When executing "ALTER TABLE sometable ALTER COLUMN somecolumn TYPE VARCHAR(7)", the whole table is re-written, and this rewrite takes many hours. During these hours, all writers on this table stall,

Re: [BUGS] BUG #4690: an select query is not using the index

2009-03-04 Thread Peter Eisentraut
vikas wrote: The following bug has been logged online: Bug reference: 4690 Logged by: vikas Email address: vikas.du...@newgen.co.in PostgreSQL version: PostgreSQL 7.3 Time to upgrade. Operating system: i686-pc-linux-gnu Description:an select query is not using th

Re: [BUGS] BUG #4689: Expanding the length of a VARCHAR column should not induce a table rewrite

2009-03-04 Thread Guillaume Smet
On Wed, Mar 4, 2009 at 11:50 AM, Peter Eisentraut wrote: > The question is how you want to implement this in a data type independent > fashion.  You can't assume that increasing the typmod is a noop for all data > types. Sure. See my previous answer on -hackers (I don't think this discussion belo

Re: [BUGS] BUG #4688: Bug in cache.

2009-03-04 Thread Heikki Linnakangas
Tom Lane wrote: Heikki Linnakangas writes: If we go down that path, how far do we go? We also know that two enums are never binary-compatible, right? Composite type and a user-defined base type? Hardly, unless you're doing something very hacky... Disallowing binary casts when any composite t

Re: [BUGS] BUG #4690: an select query is not using the index

2009-03-04 Thread Tom Lane
Peter Eisentraut writes: > vikas wrote: >> PostgreSQL version: PostgreSQL 7.3 > Time to upgrade. Indeed. 7.4 was the first release that had even an inkling of how to optimize IN (sub-SELECT) clauses. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@po

[BUGS] BUG #4692: VACUUM: write to WAL gets very slow and seems redundant

2009-03-04 Thread Peter Much
The following bug has been logged online: Bug reference: 4692 Logged by: Peter Much Email address: p...@citylink.dinoex.sub.org PostgreSQL version: 8.2.7 Operating system: FreeBSD 6.3 Description:VACUUM: write to WAL gets very slow and seems redundant Details: While

[BUGS] BUG #4693: When I use the order by it gets me an error, but if i use it without order by it's a correct query.

2009-03-04 Thread Oscar Bejarano
The following bug has been logged online: Bug reference: 4693 Logged by: Oscar Bejarano Email address: obejara...@msn.com PostgreSQL version: 8.3.0 Operating system: Suse 10 Description:When I use the order by it gets me an error, but if i use it without order by it's

[BUGS] BUG #4691: Installation error

2009-03-04 Thread Gregory Clark
The following bug has been logged online: Bug reference: 4691 Logged by: Gregory Clark Email address: gregwillcl...@hotmail.com PostgreSQL version: 8.2 Operating system: Windows Embedded Standard Description:Installation error Details: I have a Windows Embedded Stan

Re: [BUGS] BUG #4693: When I use the order by it gets me an error, but if i use it without order by it's a correct query.

2009-03-04 Thread Jaime Casanova
On Wed, Mar 4, 2009 at 2:05 PM, Oscar Bejarano wrote: > > The following bug has been logged online: > > Bug reference:      4693 > Logged by:          Oscar Bejarano > Email address:      obejara...@msn.com > PostgreSQL version: 8.3.0 > Operating system:   Suse 10 > Description:        When I use

Re: [BUGS] BUG #4691: Installation error

2009-03-04 Thread Tom Lane
"Gregory Clark" writes: > I get an error when trying to install Postgre Database Server 8.1.The Error > is "Failed to run initdb: 1! Why are you trying to install 8.1? We don't support that on Windows anymore, for good and sufficient reasons. > creating directory C:/Program Files/PostgreSQL/8.1

Re: [BUGS] BUG #4691: Installation error

2009-03-04 Thread Dave Page
On Wed, Mar 4, 2009 at 9:32 PM, Tom Lane wrote: > "Gregory Clark" writes: >> I get an error when trying to install Postgre Database Server 8.1.The Error >> is "Failed to run initdb: 1! > > Why are you trying to install 8.1?  We don't support that on Windows > anymore, for good and sufficient reas

Re: [BUGS] BUG #4691: Installation error

2009-03-04 Thread Tom Lane
Dave Page writes: > On Wed, Mar 4, 2009 at 9:32 PM, Tom Lane wrote: >> "Gregory Clark" writes: >>> The system cannot find the file specified. >>> The system cannot find the file specified. >>> The system cannot find the file specified. >>> The system cannot find the file specified. >>> The syste

Re: [BUGS] BUG #4691: Installation error

2009-03-04 Thread Dave Page
On Wed, Mar 4, 2009 at 9:47 PM, Tom Lane wrote: > Dave Page writes: >> initdb will bail out before it gets to that point if it can't find >> postgres.exe. > > Hmm.  Maybe the complaints actually come from failing to load some DLL > that postgres.exe needs. We don't delay-load anything, so we'd