Re: [BUGS] Re: BUG #5480: Autovacuum interferes with operations (e.g. truncate) on very large databases

2010-05-29 Thread Robert Haas
On Sat, May 29, 2010 at 5:44 PM, Sakari A. Maaranen wrote: > For now, I can work around this on the client side by splitting the > updates into a million separate transactions instead of a single big > one. Will be slow, but it should work. In general, it's better to group things into larger tran

Re: [BUGS] BUG #5469: regexp_matches() has poor behaviour and more poor documentation

2010-05-29 Thread Robert Haas
On Sat, May 29, 2010 at 5:00 PM, Bruce Momjian wrote: > I have updated the patch, attached, to clarify that this returns text > arrays, and that you can force it to always return one row using > COALESCE() and a '|' pattern (the later suggested by Daniele Varrazzo). I don't find this part to be s

[BUGS] Re: BUG #5480: Autovacuum interferes with operations (e.g. truncate) on very large databases

2010-05-29 Thread Sakari A. Maaranen
2010/5/29 Greg Stark : > On Fri, May 28, 2010 at 2:02 PM, Sakari Maaranen wrote: >> The documentation says that the best way to use autovacuum is to let the >> database vacuum often. However when the tables are very large, this can take >> a very long time. > > In addition to Tom's comments, as of

Re: [BUGS] BUG #5483: PQescapeStringConn behaviour ??

2010-05-29 Thread Tom Lane
"Pascal Van Puymbroeck" writes: > However if the " ë " character is at the end of a string like the name of a > country in dutch "Italië" this PQescapeStringConn function adds two > spaces. so "België" becomes "België ". The error is set to 1 which > indicates we can't trust the outcome.

Re: [BUGS] BUG #5469: regexp_matches() has poor behaviour and more poor documentation

2010-05-29 Thread Bruce Momjian
I have updated the patch, attached, to clarify that this returns text arrays, and that you can force it to always return one row using COALESCE() and a '|' pattern (the later suggested by Daniele Varrazzo). --- Bruce Momjian

[BUGS] BUG #5483: PQescapeStringConn behaviour ??

2010-05-29 Thread Pascal Van Puymbroeck
The following bug has been logged online: Bug reference: 5483 Logged by: Pascal Van Puymbroeck Email address: p...@zenonpro.be PostgreSQL version: 8.3.5 and 8.3.8 Operating system: Centos 5.4 Description:PQescapeStringConn behaviour ?? Details: Don't know whether th

Re: [BUGS] BUG #5477: CREATE DOMAIN NOT NULL constraints not always enforced for INSERT with subquery

2010-05-29 Thread Bruce Momjian
Applied. --- Bruce Momjian wrote: > Tom Lane wrote: > > "Matt Nourse" writes: > > > CREATE DOMAIN test_id_domain INT NOT NULL; > > > CREATE TABLE test_state(id test_id_domain PRIMARY KEY, display_value > > > varchar(20) NO

Re: [BUGS] BUG #5477: CREATE DOMAIN NOT NULL constraints not always enforced for INSERT with subquery

2010-05-29 Thread Kevin Grittner
Tom Lane wrote: < NOT NULL constraints at the domain level suck. Don't use 'em. +1 As someone who uses domains very heavily, I can attest that the semantics of that are very weak. Whether a domain is nullable depends almost entirely on the context of its use, which you can't (and shouldn't

[BUGS] Re: BUG #5480: Autovacuum interferes with operations (e.g. truncate) on very large databases

2010-05-29 Thread Greg Stark
On Fri, May 28, 2010 at 2:02 PM, Sakari Maaranen wrote: > The documentation says that the best way to use autovacuum is to let the > database vacuum often. However when the tables are very large, this can take > a very long time. > In addition to Tom's comments, as of 8.4 this is no longer true a