Hi
Thanks for the answers.
Really, I didn't showed you basic informations.
I used the PostgreSQL 8.4. The server configuration was:
Processor: Intel Xeon Processor W3570 Quad Core Processor
Mem: 20GB
Network Interface: Gigabit
HD: 12 x 1 TB (RAID1+0)
OS: Debian
I did that, and then realized it was time to call it an afternoon ...
Your comments have been very helpful.
Thanks
Tom
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/TRUNCATE-HANGS-tp3292333p3294007.html
Sent from the PostgreSQL - bugs mailing list archive at Nabble.co
The following bug has been logged online:
Bug reference: 5786
Logged by: Jemshir A.P
Email address: jamsheer@gmail.com
PostgreSQL version: pgsql8
Operating system: Windows Server 2003
Description:Cannot start pgsql8 application with Previleged account
(Admin accou
"Jemshir A.P" wrote:
> PostgreSQL version: pgsql8
> Operating system: Windows Server 2003
> Description:Cannot start pgsql8 application with
> Previleged account
> In the application log of the server i can find the following
> The server must be started under a
Jorge Augusto Meira writes:
> The error message was:
> "Erro Conexão: A tentativa de conexão falhou."
> or
> "Erro Conexão: FATAL: connection limit exceeded for non-superusers"
Hmm ... I can't find the first of those anywhere in the 8.4 message
lists; but the second one definitely says that you *
Hi Tom
The test program is running in other 5 client machines.
In the logs of my test program, the max_connection parameter limit is never
reached.
Regards
Jorge
On Mon, Dec 6, 2010 at 1:31 PM, Tom Lane wrote:
> Jorge Augusto Meira writes:
> > The error message was:
> > "Erro Conexão: A tenta
Jorge Augusto Meira escreveu:
> The test program is running in other 5 client machines.
> In the logs of my test program, the max_connection parameter limit is
> never reached.
>
How could the test program know? Indeed it doesn't. Are you using some delay
between one test and another one? I would
Hi, Euler
- How could the test program know?
The test program after any operation (inser, tupdate or select) receive a
message of postgres like OK or ERROR (Connection error: FATAL).
- Are you using some delay between one test and another one? I would be a
good idea, specially if you're restarti
On 05.12.2010 18:26, Tom Lane wrote:
Andres Freund writes:
On Sunday 05 December 2010 17:42:59 Tom Lane wrote:
I think the reason the given example fails is just that it's all being
done in one transaction. If the null-containing row were known dead
it wouldn't get indexed. So: commit.
Um
