Re: [BUGS] GetTokenInformation() and FreeSid() at port/exec.c

2009-07-27 Thread Magnus Hagander
On Wed, Jun 24, 2009 at 16:01, Magnus Hagander wrote: > Andrew Chernow wrote: >> >>> The only issue now is a small leak of memory in a function that is only >>> called a fixed (and very small) number of times per process. Given this, >>> I'm inclined to say we should put it on hold for 8.5. Thought

[BUGS] BUG #4944: Problems with using \set variables as strings in select statements

2009-07-27 Thread Bruno Scovoli Santos
The following bug has been logged online: Bug reference: 4944 Logged by: Bruno Scovoli Santos Email address: bruno.scov...@gmail.com PostgreSQL version: 8.3.7 Operating system: Ubuntu 9.04 Jaunty Jackalope Description:Problems with using \set variables as strings in s

Re: [BUGS] BUG #4944: Problems with using \set variables as strings in select statements

2009-07-27 Thread Tom Lane
"Bruno Scovoli Santos" writes: > brunodb=# \set nom 'Intel' > euclidhardware=# select * from fabricantes where nome like :nom; > ERROR: column "intel" does not exist > LINE 1: select * from fabricantes where nome like Intel; If you want to put quotes in the value of a variable, you need this \se

[BUGS] BUG #4943: getting error while vacuuming the database

2009-07-27 Thread fous
The following bug has been logged online: Bug reference: 4943 Logged by: fous Email address: honza...@gmail.com PostgreSQL version: 8.4.0 Operating system: Linux (CentOS release 5.3) Description:getting error while vacuuming the database Details: hi i'm getting thi

Re: [BUGS] BUG #4944: Problems with using \set variables as strings in select statements

2009-07-27 Thread Rolf Jentsch
Hallo Bruno, Am Montag, 27. Juli 2009 15:50 schrieb Bruno Scovoli Santos: >... > brunodb=# \set nom 'Intel' > euclidhardware=# select * from fabricantes where nome like :nom; > ERROR: column "intel" does not exist > LINE 1: select * from fabricantes where nome like Intel; > > Please, I have trie

[BUGS] BUG #4945: Parallel update(s) gone wild

2009-07-27 Thread dan boeriu
The following bug has been logged online: Bug reference: 4945 Logged by: dan boeriu Email address: dan.boe...@roost.com PostgreSQL version: 8.3.6 8.3.7 8.4 Operating system: Redhat Linux Description:Parallel update(s) gone wild Details: In my update I use one table

[BUGS] BUG #4946: bug - libiconv-2.dll

2009-07-27 Thread Fabiano
The following bug has been logged online: Bug reference: 4946 Logged by: Fabiano Email address: fabiano.san...@onda.com.br PostgreSQL version: 8.3 Operating system: windows Description:bug - libiconv-2.dll Details: error libiconv-2.dll -- Sent via pgsql-bugs maili

Re: [BUGS] BUG #4945: Parallel update(s) gone wild

2009-07-27 Thread Craig Ringer
On Mon, 2009-07-27 at 21:56 +, dan boeriu wrote: > What I noticed is that the second will not finish if the READ table has many > rows to be read (1 million let's say) but it finishes when the read table > has only a few 1000s of rows. > Any idea why? It could be that it _does_ finish ... eve

Re: [BUGS] BUG #4945: Parallel update(s) gone wild

2009-07-27 Thread Craig Ringer
Please reply to the list, not directly to me. > I don't think is that simple. The VERY SAME statement runs twice - one > finishes in about 20 secs the other doesn't finish in 24 hours. Yep, OK, so it's not just a planning or scaling issue. Have you checked pg_locks ? SELECT * FROM pg_locks;

[BUGS] BUG #4947: libpq PQntuples should return 64-bit number

2009-07-27 Thread Jim Michaels
The following bug has been logged online: Bug reference: 4947 Logged by: Jim Michaels Email address: jmich...@yahoo.com PostgreSQL version: 8.4.0 Operating system: Win XP Pro Sp3 Description:libpq PQntuples should return 64-bit number Details: I agree that 64-bit nu