I'm using Postgres 9.1 on Debian Lenny and via a Java server (JBoss AS 6.1) I'm
executing a simple "select ... for update" query:
SELECT
importing
FROM
customer
WHERE
id = :customer_id
FOR UPDATE NOWAIT
Once every 10 to 20 times Postgres fails to obtain the lock for no app
On 24/09/12 22:33, Kiriakos Tsourapas wrote:
Hi,
The problem : Postgres is becoming slow, day after day, and only a full vacuum
fixes the problem.
My postgresql.conf file :
==
port = 5433 # (change requires restart)
max_connections = 100
Hi,
On 24 September 2012 20:33, Kiriakos Tsourapas wrote:
> The problem : Postgres is becoming slow, day after day, and only a full
> vacuum fixes the problem.
>
> Information you may need to evaluate :
>
> The problem lies on all tables and queries, as far as I can tell, but we can
> focus on a
i remember having a server with 8.4.4 where we had multiple problems with
autovacuum.
if i am not mistaken there are some bugs related with vacuum until 8.4.7.
i would suggest you to upgrade to the latest 8.4.x version
BR,
--
View this message in context:
http://postgresql.1045698.n5.nabble.c
On 09/24/2012 15:51, Kiriakos Tsourapas wrote:
Hi,
Thank you for your response.
Please find below my answers/comments.
On Sep 24, 2012, at 15:21, Julien Cigar wrote:
Hello,
1) upgrade your PostgreSQL installation, there have been numerous bugfixes
releases since 8.4.2
Not possible right n
On Monday, September 24, 2012 02:53:59 PM Julien Cigar wrote:
> On 09/24/2012 14:34, Andres Freund wrote:
> > On Monday, September 24, 2012 02:21:09 PM Julien Cigar wrote:
> >> 5) synchronous_commit = off should only be used if you have a
> >> battery-backed write cache.
> >
> > Huh? Are you possi
Hi,
Thank you for your response.
Please find below my answers/comments.
On Sep 24, 2012, at 15:21, Julien Cigar wrote:
> Hello,
>
> 1) upgrade your PostgreSQL installation, there have been numerous bugfixes
> releases since 8.4.2
Not possible right now. It will have to be the last solution.
>
On 09/24/2012 14:34, Andres Freund wrote:
On Monday, September 24, 2012 02:21:09 PM Julien Cigar wrote:
5) synchronous_commit = off should only be used if you have a
battery-backed write cache.
Huh? Are you possibly confusing this with full_page_writes?
indeed...! sorry for that
(note that yo
On Monday, September 24, 2012 02:21:09 PM Julien Cigar wrote:
> 5) synchronous_commit = off should only be used if you have a
> battery-backed write cache.
Huh? Are you possibly confusing this with full_page_writes?
Greetings,
Andres
--
Andres Freund http://www.2ndQuadrant.
Hello,
1) upgrade your PostgreSQL installation, there have been numerous
bugfixes releases since 8.4.2
2) you'll have to show us an explain analyze of the slow queries. If I
take a look at those you provided everything run i less than 1ms.
3) with 200 records you'll always have a seqscan
4) ho
Sorry, forgot to mention the most obvious and important information :
My postgres is 8.4.2
On Sep 24, 2012, at 13:33, Kiriakos Tsourapas wrote:
> Hi,
>
> The problem : Postgres is becoming slow, day after day, and only a full
> vacuum fixes the problem.
>
> Information you may need to evaluate
Hi,
The problem : Postgres is becoming slow, day after day, and only a full vacuum
fixes the problem.
Information you may need to evaluate :
The problem lies on all tables and queries, as far as I can tell, but we can
focus on a single table for better comprehension.
The queries I am running
Jon Leighton wrote:
> I'm one of the developers of the Ruby on Rails web framework.
>
> In some situations, the framework generates an empty transaction
block.
> I.e. we sent a BEGIN and then later a COMMIT, with no other queries in
> the middle.
>
> We currently can't avoid doing this, because a
13 matches
Mail list logo