[GENERAL] The default text search configuration will be set to "simple" ?

2008-04-13 Thread Stefan Schwarzer
Hi there, what does this message mean? I didn't find any information on the web, beside of others having similar messages... -- The database cluster will be initialized with locales COLLATE: en_US.UTF-8 CTYPE:UTF-8 MESSAGES: en_US.UTF-8 MONETARY:

Re: [GENERAL] VACUUM hanging on PostgreSQL 8.3.1 for larger tables

2008-04-13 Thread Dragan Zubac
Hello If Your 'vacuum verbose analyze table' ends pretty fast,and Your 'vacuum full verbose analyze table' never ends,watch for 'select count (*) from pg_locks',might be that You have some heavy load transaction processing on that table,so 'vacuum full' wait for transactions to end. If po

Re: [GENERAL] VACUUM hanging on PostgreSQL 8.3.1 for larger tables

2008-04-13 Thread Paragon
> Yikes. That's *way* too high. If you're trying to get the vacuum to complete quickly, it really should be zero anyway. Nonzero is for when you don't care how >> long vacuum takes as long as it's not sucking too much I/O from your real work. Thanks Tom, yap you were right now it runs instan

Re: [GENERAL] No Return??

2008-04-13 Thread Ted Byers
--- Bob Pawley <[EMAIL PROTECTED]> wrote: > I'm getting a little frustrated with this problem. > > Can anyone tell me what is wrong with the following > code. > > I have tested the portions separately and they all > work. > > When I try it as a whole I get the message "control > reached end of

Re: [GENERAL] VACUUM hanging on PostgreSQL 8.3.1 for larger tables

2008-04-13 Thread Tom Lane
"Paragon" <[EMAIL PROTECTED]> writes: > Right now I have > vacuum_cost_delay = 600 Yikes. That's *way* too high. If you're trying to get the vacuum to complete quickly, it really should be zero anyway. Nonzero is for when you don't care how long vacuum takes as long as it's not sucking

Re: [GENERAL] VACUUM hanging on PostgreSQL 8.3.1 for larger tables

2008-04-13 Thread Tom Lane
"Paragon" <[EMAIL PROTECTED]> writes: >> Sure looks like a near-idle machine to me :-(. >> I think that the vacuum must be stuck on a lock. What other Postgres >> processes have you got, and what are they doing? > Originally I thought it was the autovacuuming getting in the way since I > noticed

Re: [GENERAL] VACUUM hanging on PostgreSQL 8.3.1 for larger tables

2008-04-13 Thread Paragon
> Sure looks like a near-idle machine to me :-(. > I think that the vacuum must be stuck on a lock. What other Postgres processes have you got, and what are they doing? > regards, tom lane Originally I thought it was the autovacuuming getting in the way since I noticed

Re: [GENERAL] No Return??

2008-04-13 Thread Sam Mason
On Sun, Apr 13, 2008 at 01:07:26PM -0700, Bob Pawley wrote: > When I try it as a whole I get the message "control reached end of trigger > procedure without RETURN." I've re-indented the code to make it a bit more obvious what's going on in your old version: > DECLARE > pumpnumber integer; > B

Re: [GENERAL] No Return??

2008-04-13 Thread Adrian Klaver
On Sunday 13 April 2008 1:07 pm, Bob Pawley wrote: > I'm getting a little frustrated with this problem. > > Can anyone tell me what is wrong with the following code. > > I have tested the portions separately and they all work. > > When I try it as a whole I get the message "control reached end of t

Re: [GENERAL] No Return??

2008-04-13 Thread Harald Armin Massa
Bob, if pumpnumber not in (1,2) that function does not return anything. > End If; > at this end if it ends so you have to return sth. here > END; Harald -- GHUM Harald Massa persuadere et programmare Harald Armin Massa Spielberger Straße 49 70435 Stuttgart 0173/9409607 fx 01212-5-13695179

Re: [GENERAL] No Return??

2008-04-13 Thread Raymond O'Donnell
On 13/04/2008 21:07, Bob Pawley wrote: When I try it as a whole I get the message "control reached end of trigger procedure without RETURN." Hi Bob, If the "IF" branch of the outer IF is executed, then the flow of execution won't hit a RETURN anywhere; I reckon this is what's causing the e

[GENERAL] No Return??

2008-04-13 Thread Bob Pawley
I'm getting a little frustrated with this problem. Can anyone tell me what is wrong with the following code. I have tested the portions separately and they all work. When I try it as a whole I get the message "control reached end of trigger procedure without RETURN." Any help greatly appreci

Re: [GENERAL] SQL injection, php and queueing multiple statement

2008-04-13 Thread Stephan Szabo
On Sun, 13 Apr 2008, Ivan Sergio Borgonovo wrote: > On Sun, 13 Apr 2008 16:02:35 +0800 > Craig Ringer <[EMAIL PROTECTED]> wrote: > > > > I think this logic is already somewhere in the driver or the pg > > > engine. Whatever you write at the application level a) risk to be > > > a duplication of pa

Re: [GENERAL] VACUUM hanging on PostgreSQL 8.3.1 for larger tables

2008-04-13 Thread Tom Lane
"Paragon" <[EMAIL PROTECTED]> writes: >> Is it actually *doing* anything, like consuming CPU or I/O -- and if so >> which? How much does VACUUM VERBOSE print before getting stuck? > --If I start the > vacuum verbose ky.ky_edges; > and monitor vmstat 1 looks like this Sure looks like a near-idl

Re: [GENERAL] SQL injection, php and queueing multiple statement

2008-04-13 Thread Ivan Sergio Borgonovo
On Sun, 13 Apr 2008 11:49:58 +0200 Martijn van Oosterhout <[EMAIL PROTECTED]> wrote: > On Sun, Apr 13, 2008 at 10:37:52AM +0200, Ivan Sergio Borgonovo > wrote: > > > Because you appear to be seeking something to protect against > > > programmers who do not follow coding guidelines, and that shoul

Re: [GENERAL] SQL injection, php and queueing multiple statement

2008-04-13 Thread Martijn van Oosterhout
On Sun, Apr 13, 2008 at 10:37:52AM +0200, Ivan Sergio Borgonovo wrote: > > Because you appear to be seeking something to protect against > > programmers who do not follow coding guidelines, and that should > > help even if code review processes fail to catch the problem. Were > > that not the case

Re: [GENERAL] SQL injection, php and queueing multiple statement

2008-04-13 Thread Ivan Sergio Borgonovo
On Sun, 13 Apr 2008 16:02:35 +0800 Craig Ringer <[EMAIL PROTECTED]> wrote: > > I think this logic is already somewhere in the driver or the pg > > engine. Whatever you write at the application level a) risk to be > > a duplication of part of the parser b) risk to be less smart than > > the parser

Re: [GENERAL] SQL injection, php and queueing multiple statement

2008-04-13 Thread Craig Ringer
Ivan Sergio Borgonovo wrote: On Sun, 13 Apr 2008 10:03:48 +0800 Craig Ringer <[EMAIL PROTECTED]> wrote: Your wrapper code can potentially do things like scan a string for semicolons not enclosed in single or double quotes. The rule probably has to be a little more complex than that, and has

Re: [GENERAL] SQL injection, php and queueing multiple statement

2008-04-13 Thread Ivan Sergio Borgonovo
On Sun, 13 Apr 2008 10:03:48 +0800 Craig Ringer <[EMAIL PROTECTED]> wrote: > Your wrapper code can potentially do things like scan a string for > semicolons not enclosed in single or double quotes. The rule > probably has to be a little more complex than that, and has to > handle escaped quotes,