Re: [GENERAL] SQL injection, php and queueing multiple statement
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, but it might achieve what you want.
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 itself and let slip something.
> Personally I doubt it's worth it for the questionable benefits
> gained over following a strong coding standard and having good code
> review.
> I do think that for web scripting users it would be nice for DB
> drivers to optionally throw an error if an execute call passes more
> than one statement. Your problem would be that it'd need to be an
> option that affects the whole app instance for it to achieve what
> you want without developer action, and a global option like that
> would potentially break 3rd party application code. The alternative
> would be something like an executeSingle(...) call or a flag to
> execute ... but that again just comes back to proper code review to
> ensure it's used.
Why does it have to be "global", couldn't it be "by connection" or
"by call to pg_query"?
On Sun, 13 Apr 2008 00:13:49 +0100
Sam Mason <[EMAIL PROTECTED]> wrote:
> On Sat, Apr 12, 2008 at 11:06:42PM +0200, Ivan Sergio Borgonovo
> wrote:
> > But what about already written code that use pg_query?
>
> If you rewrite the database interface then it doesn't matter, the
> calls to pg_query will end up being calls to prepare/execute
> underneath so you'll have their protection. If you mean that
Sorry to everybody for not testing first what you were suggesting in
chorus.
function test_me() {
$result=pg_prepare("tonno","
select ItemID from catalog_items limit 1;
create table tonno(au int);");
$result=pg_execute("tonno");
return "pippo";
}
Query failed: ERROR: cannot insert multiple commands into a prepared
statement in ...
Not something easy to deploy after the cats are out, but at least I've
learnt something.
thanks
--
Ivan Sergio Borgonovo
http://www.webthatworks.it
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] SQL injection, php and queueing multiple statement
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 to handle escaped quotes, but it might achieve what you want. 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 itself and let slip something. ... in which case it sounds like you need to extend the Pg DB interface to do what you want. It might be worth hacking together a proof of concept and posting it to -hackers and the PHP interface maintainers, along with a rationale for its inclusion. I do think that for web scripting users it would be nice for DB drivers to optionally throw an error if an execute call passes more than one statement. Your problem would be that it'd need to be an option that affects the whole app instance for it to achieve what you want without developer action, and a global option like that would potentially break 3rd party application code. The alternative would be something like an executeSingle(...) call or a flag to execute ... but that again just comes back to proper code review to ensure it's used. Why does it have to be "global", couldn't it be "by connection" or "by call to pg_query"? 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 you'd be able to use some of the other suggestions made here. I quote: Yeah... but how can I effectively enforce the policy that ALL input will be passed through prepared statements? If I can't, and I doubt there is a system that will let me enforce that policy at a reasonable cost, why not providing a safety net that will at least raise the bar for the attacker at a very cheap cost? If programmers didn't make errors or errors where cheap to find there How can you ensure that programmers will set the single statement flag on each connection or set the flag on each query? If you can do those things, you can also ensure that they just follow string handling rules, use prepared statements where possible, require additional review of all non-prepared-statement code, etc. An app instance wide flag at least ensure that it's set once (say, in PHP configuration) and *stays* set, no matter what stupid things individual developers might do. For more general use a per-query and per-connection flag would be useful, but it doesn't sound like it would fit your specific needs unless you can hide the DB interface behind a connection factory that you can ensure will always set the option. You could also have a per-query-call flag to permit multiple statements; it'd be something for library authors to use where required no matter what the connection and global defaults were, ensuring they always got correct behaviour. Such a flag would also be easy to scan for in automated code review or in a revision control system hook script. Also, as already noted there are ways to help you enforce the use of prepared statements. If you have a decent code review process in place then you probably have a `lint' script that's run as a first pass to spot possible problems in the code. You can extend that script, and also hook it into the revision control system so it emails you (or rejects the commit) if somebody tries to commit code that looks worrying, like non-prepared-query database interface calls. A simple annotation scheme should permit you to ignore the legit ones, with unauthorized addition of annotations punishable by cold coffee for a year. There's probably an existing PHP lint script you can extend, so you don't have to do the boring bits. A quick search suggests so. Ideally you want a lint script or PHP extension that can also do static and/or runtime analysis for user input `taint', like the Perl option of the same name. A Google search for `php taint' suggests that there are certainly efforts in that direction, though not being active in PHP it's hard for me to tell how complete or useful they are. In any case, I agree with you that a "single statement only" flag would be nice in the DB interface, because as you say it's nice if all else fails and will block a many of the most flexible types of SQL injection attack. I just think that if it exists it needs to be opt-out, not opt-in, to be significantly effective as a defense against other programming errors. -- Craig Ringer -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] SQL injection, php and queueing multiple statement
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 itself and let slip something. > ... in which case it sounds like you need to extend the Pg DB > interface to do what you want. It might be worth hacking together a > proof of concept and posting it to -hackers and the PHP interface > maintainers, along with a rationale for its inclusion. I wish I'd be so familiar with pg C code. And it looks as if such a thing won't be that welcome. Everybody seems happy with pg_prepare|execute and consider not using them shameful enough not to be worth some form of "legacy support". > > Why does it have to be "global", couldn't it be "by connection" or > > "by call to pg_query"? > 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 you'd be able to use some of the other > suggestions made here. I quote: Default 1 statement, switch to more than one have to be "voluntary" and "conscious" and can be easily spotted with grep only. > Also, as already noted there are ways to help you enforce the use > of prepared statements. If you have a decent code review process in > place then you probably have a `lint' script that's run as a first > pass to spot possible problems in the code. You can extend that > script, and also hook it into the revision control system so it > emails you (or rejects the commit) if somebody tries to commit code > that looks worrying, like non-prepared-query database interface > calls. A simple annotation scheme should permit you to ignore the > legit ones, with unauthorized addition of annotations punishable by > cold coffee for a year. These things are nice... and I do as much as I can to deal with security from different angles but they require more effort than switching a flag. > There's probably an existing PHP lint script you can extend, so you > don't have to do the boring bits. A quick search suggests so. These will be further steps as soon as I'll have some free time. That said php as a language doesn't make easy to deal with static checking and I had (?) the feeling many tools are still in their infancy (eg. automatic refactoring tools that will make easier to wrap all the calls of pg_query). But this is definitively OT for the Postgresql list. > In any case, I agree with you that a "single statement only" flag > would be nice in the DB interface, because as you say it's nice if > all else fails and will block a many of the most flexible types of > SQL injection attack. I just think that if it exists it needs to be > opt-out, not opt-in, to be significantly effective as a defense > against other programming errors. thanks -- Ivan Sergio Borgonovo http://www.webthatworks.it -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] SQL injection, php and queueing multiple statement
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 you'd be able to use some of the other
> > suggestions made here. I quote:
>
> Default 1 statement, switch to more than one have to be "voluntary"
> and "conscious" and can be easily spotted with grep only.
It's not quite so simple, there are backward compatability issues.
Postgres supported multiple queries in one string since forever and
there is a huge amount of code written and still being written that
takes advantage of this. Most in contexts where SQL injection is simply
not an issue since they're static queries.
PQexec("BEGIN; CREATE TABLE ... ; CREATE TABLE ...; etc; COMMIT;");
For dynamic queries people were using prepared statements already so it
made sense to restrict it for prepared statements and leave one-shot
queries alone. You are advocating catering to a coding style that has
been discouraged for years.
If you want definitive answer I suppose you need to check the archives
at the time this decision was made, which is quite some time back.
Have a nice day,
--
Martijn van Oosterhout <[EMAIL PROTECTED]> http://svana.org/kleptog/
> Please line up in a tree and maintain the heap invariant while
> boarding. Thank you for flying nlogn airlines.
signature.asc
Description: Digital signature
Re: [GENERAL] SQL injection, php and queueing multiple statement
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 should > > > help even if code review processes fail to catch the problem. > > > Were that not the case you'd be able to use some of the other > > > suggestions made here. I quote: > > > > Default 1 statement, switch to more than one have to be > > "voluntary" and "conscious" and can be easily spotted with grep > > only. > > It's not quite so simple, there are backward compatability issues. I'm aware of the problem. I couldn't use legacy as an argument just to break other legacy stuff ;) Actually I pointed out that giving no option is a bad idea, and that's what mysql driver do, if I remember correctly. I'd say default at the application level. While it is pretty common to call pg_query directly, places where you use pg_connect are fewer and generally is something less frequently called directly and already wrapped into something that will load connection parameters. You'd switch multiple statement off (but still not at the connection level) when you use pg_connect and if you want multiple statements you'd have to turn it on before you issue a pg_query, and turn it off afterwards. Of course if pg_query is NEVER (or very seldom) called directly in the code... you'd already have a wrapper to turn every pg_query into a pg_prepare + pg_execute sequence. I'm not here to ask anyone will implement my ideas in the postgres driver for php ;) and from what I've learnt on pg_prepare/pg_execute I've enough tools to mitigate the problem at least in MY code since pg_query is NEVER called directly. I thought that _prepare _execute was just a more conscious form of fprint... while it is not. So I kept thinking that it was still possible to inject multiple statements. thanks to everybody who insisted enough to let me grasp what you were writing by a long time. -- Ivan Sergio Borgonovo http://www.webthatworks.it -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] VACUUM hanging on PostgreSQL 8.3.1 for larger tables
"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-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 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] SQL injection, php and queueing multiple statement
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 part of the parser b) risk to be less smart than > > > the parser itself and let slip something. > > > ... in which case it sounds like you need to extend the Pg DB > > interface to do what you want. It might be worth hacking together a > > proof of concept and posting it to -hackers and the PHP interface > > maintainers, along with a rationale for its inclusion. > > I wish I'd be so familiar with pg C code. > And it looks as if such a thing won't be that welcome. Well, Tom suggested making the PHP interface optionally use PQexecParams rather than PQexec even when using a full query string with no parameters as that interface doesn't support multiple queries, so I don't think it's necessarily entirely unwelcome - of course, we're not the PHP team, so they might view it differently. One issue is that it appears that PHP's interface tries to support cases where the libpq version doesn't have PQexecParams, and you'd probably be best to follow the existing style, only using PQexecParams if HAVE_PQEXECPARAMS and the configuration option is set. There appear to be 15 calls to PQexec inside the PHP ext/pgsql.c for the version I have of PHP. 7 of them appear to use a constant string in the call, so don't necessarily need to change. A few of the others are generated single queries for metadata and the like and probably don't need to be configurable to allow multiple queries but merely on HAVE_PQEXECPARAMS. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] No Return??
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 appreciated. Bob Declare pumpnumber integer; Begin Select count(*) Into pumpnumber From p_id.devices, p_id.processes Where device_number = '11' and p_id.devices.fluid_id = p_id.processes.fluid_id and p_id.processes.ip_op_equipment = 'op'; If pumpnumber = 1 then Update p_id.devices Set number = '#1' From p_id.processes Where p_id.devices.number is null and p_id.devices.device_number = '11' and p_id.devices.fluid_id = p_id.processes.fluid_id and p_id.processes.ip_op_equipment = 'op' ; Else If pumpnumber = 2 Then Update p_id.devices Set number = '#2' From p_id.processes Where p_id.devices.number is null and p_id.devices.device_number = '11' and p_id.devices.fluid_id = p_id.processes.fluid_id and p_id.processes.ip_op_equipment = 'op' ; End If; RETURN NULL; End If; END; I have tried 'Return New' and 'Return Result' without luck, and if I leave off either of the two 'End If ' statements the procedure returns an error. B -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] No Return??
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 error. HTH, Ray. -- Raymond O'Donnell, Director of Music, Galway Cathedral, Ireland [EMAIL PROTECTED] Galway Cathedral Recitals: http://www.galwaycathedral.org/recitals -- -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] No Return??
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 - EuroPython 2008 will take place in Vilnius, Lithuania - Stay tuned! -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] No Return??
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 trigger > procedure without RETURN." > > Any help greatly appreciated. > > Bob > > Declare > pumpnumber integer; > > Begin > > Select count(*) Into pumpnumber From p_id.devices, p_id.processes > Where device_number = '11' > and p_id.devices.fluid_id = p_id.processes.fluid_id > and p_id.processes.ip_op_equipment = 'op'; > > If pumpnumber = 1 then > Update p_id.devices > Set number = '#1' > From p_id.processes > Where p_id.devices.number is null > and p_id.devices.device_number = '11' > and p_id.devices.fluid_id = p_id.processes.fluid_id > and p_id.processes.ip_op_equipment = 'op' ; > > Else If pumpnumber = 2 Then Should be elsif or elseif > Update p_id.devices > Set number = '#2' > From p_id.processes > Where p_id.devices.number is null > and p_id.devices.device_number = '11' > and p_id.devices.fluid_id = p_id.processes.fluid_id > and p_id.processes.ip_op_equipment = 'op' ; > > End If; > RETURN NULL; > End If; Eliminate this End if . > END; > > I have tried 'Return New' and 'Return Result' without luck, and if I leave > off either of the two 'End If ' statements the procedure returns an error. > > B -- Adrian Klaver [EMAIL PROTECTED] -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] No Return??
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; > BEGIN > SELECT count(*) INTO pumpnumber [...] > IF pumpnumber = 1 THEN > UPDATE p_id.devices [...] > ELSE > IF pumpnumber = 2 THEN > UPDATE p_id.devices [...] > END IF; > RETURN NULL; > END IF; > END; > > I have tried 'Return New' and 'Return Result' without luck, and if I leave > off either of the two 'End If ' statements the procedure returns an error. I think you're looking for either "ELSIF" or "ELSEIF", you've got white space between the ELSE and the IF which is introducing a new sub-expression. Either that, or move the RETURN after the final END IF. Sam -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] VACUUM hanging on PostgreSQL 8.3.1 for larger tables
> 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 sometimes it was trying to vacuum the tables I was trying to vacuum and autovacuuming was taking a long time, but I had turned autovacuuming off during bulk load process period to prevent this. When I showed you the stats on only the vacuuming, I had already stopped all bulk load processes such that Running SELECT * FROM pg_stat_activity Was showing nothing but my single vacuuming process. If I vacuum say a 365, record table of comparable structure to my 1 million someodd, it takes about 10 minutes to run and runs thru. 10 minutes for 365,000 records seemed a little long to me from memory on 8.2, but at least it ran thru okay. Next I was going to try to do was load the same dataset on my old 8.2 box to rule out 8.3.1 as the culprit. Thanks, Regina -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] VACUUM hanging on PostgreSQL 8.3.1 for larger tables
"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 sometimes it was trying to vacuum the tables I was trying to vacuum > and autovacuuming was taking a long time, but I had turned autovacuuming off > during bulk load process period to prevent this. Hmm ... another reason for vacuum running really slowly would be poor choices of vacuum_cost parameters --- have you got those set to nondefault values? regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] VACUUM hanging on PostgreSQL 8.3.1 for larger tables
"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 too much I/O from your real work. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] No Return??
--- 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 trigger > procedure without RETURN." > > Any help greatly appreciated. > > Bob > > Declare > pumpnumber integer; > > Begin > > Select count(*) Into pumpnumber From p_id.devices, > p_id.processes > Where device_number = '11' > and p_id.devices.fluid_id = p_id.processes.fluid_id > and p_id.processes.ip_op_equipment = 'op'; > > If pumpnumber = 1 then > Update p_id.devices > Set number = '#1' > From p_id.processes > Where p_id.devices.number is null > and p_id.devices.device_number = '11' > and p_id.devices.fluid_id = p_id.processes.fluid_id > and p_id.processes.ip_op_equipment = 'op' ; > > Else If pumpnumber = 2 Then > Update p_id.devices > Set number = '#2' > From p_id.processes > Where p_id.devices.number is null > and p_id.devices.device_number = '11' > and p_id.devices.fluid_id = p_id.processes.fluid_id > and p_id.processes.ip_op_equipment = 'op' ; > > End If; > RETURN NULL; > End If; > END; > > I have tried 'Return New' and 'Return Result' > without luck, and if I leave > off either of the two 'End If ' statements the > procedure returns an error. > Look at your flow control! Your return is within a conditional block. If the condition for your first returns false, flow goes to the very end of the function and reaches "end" without encountering a return statement. Cheers, Ted -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] VACUUM hanging on PostgreSQL 8.3.1 for larger tables
> 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 instantaneously by resetting vacuum back to defaults. I feel kind of dumb at this point :) I guess misunderstood the docs. Thanks again, Regina -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] VACUUM hanging on PostgreSQL 8.3.1 for larger tables
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 possible kill all processes that access that table and try 'vacuum full verbose analyze table'. Anyway,if processor is mostly idle,always check 'select count (*) from pg_locks' , at least in my experience. Sincerely Dragan Zubac Tom Lane wrote: "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 too much I/O from your real work. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] The default text search configuration will be set to "simple" ?
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: en_US.UTF-8 NUMERIC: en_US.UTF-8 TIME: en_US.UTF-8 The default database encoding has accordingly been set to UTF8. initdb: could not find suitable text search configuration for locale UTF-8 The default text search configuration will be set to "simple". -- Thanks for any advice, Stef -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
