Re: [GENERAL] Connection pool

2010-09-05 Thread Sergey Konoplev
Hi, On 6 September 2010 10:34, Mark Paylaga wrote: > Hi sorry if this has been asked already. > Is there any mechanism to do connection pooling for libpqxx already? > Or any new developments for this? > > Our one dbwriter service instance recieves requests simultaneously to write > to the databa

[GENERAL] Connection pool

2010-09-05 Thread Mark Paylaga
Hi sorry if this has been asked already. Is there any mechanism to do connection pooling for libpqxx already? Or any new developments for this? Our one dbwriter service instance recieves requests simultaneously to write to the database. We need separate db connections for each request. The simp

Re: [GENERAL] FC13 RPMs for 9.0 - on postgresql.org ftp, but not in yum repo?

2010-09-05 Thread Devrim GÜNDÜZ
On Sun, 2010-09-05 at 21:15 +0800, Craig Ringer wrote: > > I've been thinking of switching from using git builds of 9.0 to the > RC > now that it's out, so I can do some testing on the proposed release > packaging. > > It seems that the FC13 PGDG RPMs appear here: > > http://www.postgresql.org

Re: [GENERAL] Vacuum full progress

2010-09-05 Thread Carlos Henrique Reimer
Hi, I thought about this approach but this gave big troubles in the past. Basically the problem of this is that views and functions will still work on the old_table_bak and not the new_table. This can work but all views and functions linked to the old_table must be recreated. Something that needs

Re: [GENERAL] Vacuum full progress

2010-09-05 Thread Scott Marlowe
On Sun, Sep 5, 2010 at 5:09 AM, Carlos Henrique Reimer wrote: > Hi Alban, > > The need for the vacuum full is because there were a problem with the daily > schedulled vacuum analyze and autovacuum regarding the max_fsm_pages. As it > was underestimated the vacuum process was not able to flag the p

Re: [GENERAL] How can I use parameters in plain sql

2010-09-05 Thread Cédric Villemain
2010/9/3 Merlin Moncure : > On Fri, Sep 3, 2010 at 3:47 PM, John Adams wrote: >>> psql has some client side manged variables, and you can of course use >>> pl/pgsql. >> Do you mean I should use a pl/pgsql stored procedure or do I have to somehow >> mark the sql as pl/pgsql? How? >> Because in sql

Re: [GENERAL] does record_eq() ignore user-defined operators?

2010-09-05 Thread Tom Lane
Kurt writes: > i'm trying to replicate tables containing XML-fields using Pg 8.4.4 and > 9.0B4 with Bucardo and got: > DBD::Pg::st execute failed: ERROR: could not identify an equality > operator for type xml > So i provided a primitive equality operator for the XML type in schema > pg_catalo

[GENERAL] does record_eq() ignore user-defined operators?

2010-09-05 Thread Kurt
Dear list, i'm trying to replicate tables containing XML-fields using Pg 8.4.4 and 9.0B4 with Bucardo and got: DBD::Pg::st execute failed: ERROR: could not identify an equality operator for type xml So i provided a primitive equality operator for the XML type in schema pg_catalog: CREATE

[GENERAL] FC13 RPMs for 9.0 - on postgresql.org ftp, but not in yum repo?

2010-09-05 Thread Craig Ringer
Hi I've been thinking of switching from using git builds of 9.0 to the RC now that it's out, so I can do some testing on the proposed release packaging. It seems that the FC13 PGDG RPMs appear here: http://www.postgresql.org/ftp/binary/v9.0rc1/linux/rpms/fedora/fedora-13-x86_64/ but not in

Re: [GENERAL] Vacuum full progress

2010-09-05 Thread Carlos Henrique Reimer
Hi Alban, The need for the vacuum full is because there were a problem with the daily schedulled vacuum analyze and autovacuum regarding the max_fsm_pages. As it was underestimated the vacuum process was not able to flag the pages to be reused. I've cancelled the vacuum full and will think anothe

Re: [GENERAL] Vacuum full progress

2010-09-05 Thread Alban Hertroys
On 5 Sep 2010, at 12:13, Carlos Henrique Reimer wrote: > Hi, > > I need to shrick a table with 102 GB and approximately 380.000.000 rows. What exactly are you trying to accomplish? You may be saving some space temporarily by running vacuum full and reindex, but the database size will probably

[GENERAL] Vacuum full progress

2010-09-05 Thread Carlos Henrique Reimer
Hi, I need to shrick a table with 102 GB and approximately 380.000.000 rows. There is a vacuum full running for 13 hours and the only messages a get are: INFO: vacuuming "public.posicoes_controles" INFO: "posicoes_controles": found 43960 removable, 394481459 nonremovable row versions in 133089

Re: [GENERAL] stack depth limit exceeded

2010-09-05 Thread Thom Brown
On 5 September 2010 10:13, Ovid wrote: > I'm getting the following error from Postgres: > >  ERROR:  stack depth limit exceeded >  HINT:  Increase the configuration parameter "max_stack_depth", after ensuring > the platform's stack depth limit is adequate. >  CONTEXT:  SQL statement "UPDATE _test_

[GENERAL] stack depth limit exceeded

2010-09-05 Thread Ovid
I'm getting the following error from Postgres: ERROR: stack depth limit exceeded HINT: Increase the configuration parameter "max_stack_depth", after ensuring the platform's stack depth limit is adequate. CONTEXT: SQL statement "UPDATE _test_changed_table SET updates = updates + 1 WHERE