Re: [BUGS] BUG #5274: [PL/PgSQL] EXECUTE ... USING variable expansion

2010-01-14 Thread Pavel Stehule
Hello it is not bug. DDL statements like CREATE TABLE, ALTER TABLE are doesn't support parametrisation - you cannot use a placeholder for parameter everywhere. So you cannot to write PQexecParams(...ALTER TABLE test ALTER COLUMN $1 ..., ...), so it cannot be supported by EXECUTE USING.

Re: [BUGS] BUG #5274: [PL/PgSQL] EXECUTE ... USING variable expansion

2010-01-14 Thread Vincenzo Romano
2010/1/14 Pavel Stehule pavel.steh...@gmail.com: Hello it is not bug. DDL statements like CREATE TABLE, ALTER TABLE are doesn't support parametrisation - you cannot use a placeholder for parameter everywhere. So you cannot to write PQexecParams(...ALTER TABLE test ALTER COLUMN $1 ...,

Re: [BUGS] BUG #5274: [PL/PgSQL] EXECUTE ... USING variable expansion

2010-01-14 Thread Pavel Stehule
2010/1/14 Vincenzo Romano vincenzo.rom...@notorand.it: 2010/1/14 Pavel Stehule pavel.steh...@gmail.com: Hello it is not bug. DDL statements like CREATE TABLE, ALTER TABLE are doesn't support parametrisation - you cannot use a placeholder for parameter everywhere. So you cannot to write

Re: [BUGS] BUG #5274: [PL/PgSQL] EXECUTE ... USING variable expansion

2010-01-14 Thread Pavel Stehule
Pavel, if it was a simple plain dynami statement, I could create it by string concatenation, literal_ and ident_ quoting and so on. the situation isn't too simply like you see it. PostgreSQL supports composite and nested types. For this types you cannot use quote* functions. Next problem is

Re: [BUGS] Substring auto trim

2010-01-14 Thread Charles O'Farrell
On Thu, Jan 14, 2010 at 3:21 AM, Kevin Grittner kevin.gritt...@wicourts.gov wrote: I'm inclined to agree with you, but it does present a barrier to those migrating. Are there any migration considerations documents where we should mention this? Standards compliance notes in the docs? Some

[BUGS] BUG #5277: plperl can't get args properly

2010-01-14 Thread louis
The following bug has been logged online: Bug reference: 5277 Logged by: louis Email address: louis01010...@gmail.com PostgreSQL version: 8.4.2 Operating system: PostgreSQL 8.4.2 on x86_64-pc-linux-gnu, compiled by GCC gcc-4.4.real (Ubuntu 4.4.1-4ubuntu8) 4.4.1, 64-bit

Re: [BUGS] BUG #5269: postgres backend terminates with SIGSEGV

2010-01-14 Thread Tom Lane
Justin Pitts jpi...@bplglobal.net writes: My guess is that I am not provoking a 'SI queue overrun' The 100 temp table creations probably will do that just fine. Am I completely off base about how this should be reproducing? Two points: the session you hope to have crash *must* be in

Re: [BUGS] BUG #5269: postgres backend terminates with SIGSEGV

2010-01-14 Thread Tom Lane
BTW --- from my own perspective, what is much more interesting is testing time on your real application to make sure that you don't see a crash any more. I am certain that I identified and fixed *a* bug, what I'm less certain about is that it is actually what you were hitting. The previous

Re: [BUGS] BUG #5269: postgres backend terminates with SIGSEGV

2010-01-14 Thread Justin Pitts
Apologies for over-quoting on the previous message. My approach to a regression test was this single-threaded test ( actual code at bottom ) Connection 1 - implicitly autocommiting every statement create a test table and populate it with a single row.

Re: [BUGS] BUG #5276: pg_ctl reads data directory on -D instead of postgresql.conf directoryh

2010-01-14 Thread Tom Lane
James Bellinger j...@zer7.com writes: While on startup, pg_ctl (correctly) looks in the directory specified by -D for postgresql.conf, and then uses that to determine the data directory, when stopping it actually expects the directories to be the same and in doing so looks for the PID file in

Re: [BUGS] BUG #5269: postgres backend terminates with SIGSEGV

2010-01-14 Thread Justin Pitts
As difficult as it was to reproduce the bug, I'd like a clear cut regression test. The use case where it manifested is fairly rare in normal use - server start after prolonged outage, where the queue of inbound device events is built up enough to make serialization errors more likely. On Jan

Re: [BUGS] BUG #5269: postgres backend terminates with SIGSEGV

2010-01-14 Thread Justin Pitts
On Jan 14, 2010, at 10:16 AM, Tom Lane wrote: Justin Pitts jpi...@bplglobal.net writes: My guess is that I am not provoking a 'SI queue overrun' The 100 temp table creations probably will do that just fine. Is there a way to verify this? Am I completely off base about how this

Re: [BUGS] BUG #5277: plperl can't get args properly

2010-01-14 Thread Tom Lane
louis louis01010...@gmail.com writes: Arguments can't be passed to a plperl function [ scratches head... ] Works for everybody else. I have to suppose there's something broken about your libperl, or plperl somehow got built wrong. How did you build or come by your copies of perl and

Re: [BUGS] BUG #5277: plperl can't get args properly

2010-01-14 Thread Alex Hunsaker
On Thu, Jan 14, 2010 at 04:06, louis louis01010...@gmail.com wrote: Arguments can't be passed to a plperl function Yeah, this is a bug with safe 2.20 :( see -http://rt.perl.org/rt3/Ticket/Display.html?id=72068 I would either try out this fix: http://github.com/timbunce/Safe/commits/master. Or

Re: [BUGS] BUG #5277: plperl can't get args properly

2010-01-14 Thread David E . Wheeler
Tom Lane t...@sss.pgh.pa.us writes: louis louis01010...@gmail.com writes: Arguments can't be passed to a plperl function [ scratches head... ] Works for everybody else. I have to suppose there's something broken about your libperl, or plperl somehow got built wrong. How did you build

Re: [BUGS] Termination When Switching between PL/Perl and PL/PerlU

2010-01-14 Thread Tim Bunce
David E. Wheeler wrote: Found in 8.4.2, replicated in HEAD. Steps: 1. Create PL/Perl function. 2. Run it. 3. Create same function with PL/PerlU 4. Run it. 5. Create same function again with PL/Perl 6. Boom. This was just discussed in -HACKERS. Have a look at the archives.

Re: [BUGS] BUG #5269: postgres backend terminates with SIGSEGV

2010-01-14 Thread Justin Pitts
On Jan 14, 2010, at 10:44 AM, Tom Lane wrote: Justin Pitts jpi...@bplglobal.net writes: On Jan 14, 2010, at 10:16 AM, Tom Lane wrote: The 100 temp table creations probably will do that just fine. Is there a way to verify this? You could add an elog(LOG, message) into ResetPlanCache so

Re: [BUGS] BUG #5235: Segmentation fault under high load through JDBC

2010-01-14 Thread Oleg Jurtšenko
After upgrading to the latest patch level: PostgreSQL 8.4.2 on i386-portbld-freebsd8.0 I have got a different core dump (gdb) bt #0 0x328b1068 in malloc () from /lib/libc.so.7 #1 0x082f1be9 in load_tzoffsets () #2 0x080aa5ef in btrescan () #3 0x082db80c in FunctionCall2 () #4 0x080a4c15

Re: [BUGS] Termination When Switching between PL/Perl and PL/PerlU

2010-01-14 Thread Tim Bunce
On Thu, Jan 14, 2010 at 06:41:52PM +, Tim Bunce wrote: David E. Wheeler wrote: Found in 8.4.2, replicated in HEAD. Steps: 1. Create PL/Perl function. 2. Run it. 3. Create same function with PL/PerlU 4. Run it. 5. Create same function again with PL/Perl 6. Boom.

[BUGS] BUG #5278: Postgres hangs / crashes every day

2010-01-14 Thread Murali
The following bug has been logged online: Bug reference: 5278 Logged by: Murali Email address: nmmredd...@hotmail.com PostgreSQL version: 8.0.6 Operating system: Windows Server 2003 Standard 32 Bit Description:Postgres hangs / crashes every day Details: Postgres

Re: [BUGS] BUG #5278: Postgres hangs / crashes every day

2010-01-14 Thread Tom Lane
Murali nmmredd...@hotmail.com writes: Postgres hangs / crashes every day (gets corrupted?). It neither serves any requests from connected applications nor accepts new connections. I can’t connect to the data base through PG Admin also. Below given is the log snippet at the time of failure.

Re: [BUGS] BUG #5278: Postgres hangs / crashes every day

2010-01-14 Thread Kevin Grittner
Murali nmmredd...@hotmail.com wrote: PostgreSQL version: 8.0.6 Operating system: Windows Server 2003 Standard 32 Bit Description:Postgres hangs / crashes every day You do realize that Windows is not a supported platform for any release less than 8.2?