Hi Guys,
We found the issue regarding our memory leak. It was the query. It
seams were using functions with fetch cursors on large data sets and the
cursors were not getting closed properly. Hence the memory was building up.
So I guess this was an application error. In fact we bought the Qu
Gregory Stark <[EMAIL PROTECTED]> writes:
> I must be misunderstanding Tom's comment then.
> What I'm referring to is lazy_vacuum_rel() calls vacuum_set_xid_limits with
> the relisshared flag of the relation. vacuum_set_xid_limits passes that to
> GetOldestXmin as the allDbs parameter. GetOldestX
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Gregory Stark wrote:
> > Tom Lane <[EMAIL PROTECTED]> writes:
> >
> > > Matteo Sgalaberni <[EMAIL PROTECTED]> writes:
> > > > Good to know this...but why this behaviour? it'is lovely...:)
> > >
> > > Open transactions are tracked across the whole clu
Gregory Stark wrote:
> Tom Lane <[EMAIL PROTECTED]> writes:
>
> > Matteo Sgalaberni <[EMAIL PROTECTED]> writes:
> > > Good to know this...but why this behaviour? it'is lovely...:)
> >
> > Open transactions are tracked across the whole cluster. This is
> > necessary when vacuuming shared catalogs
Tom Lane <[EMAIL PROTECTED]> writes:
> Matteo Sgalaberni <[EMAIL PROTECTED]> writes:
> > Good to know this...but why this behaviour? it'is lovely...:)
>
> Open transactions are tracked across the whole cluster. This is
> necessary when vacuuming shared catalogs. In principle we could
> track pe
Hi.
My config:
gentoo linux "2005.1" on amd64x2 in 64-bit mode,
kernel 2.6.16.12
glibc 3.3.5(NPTL),
gcc 3.4.3.
I had not used portage for building.
I built two versions of postgres from sources:
postgresql-8.1.4 native(64bit)
and 32-bit with CFLAGS=... -m32, and "LD =
/usr/x86_64-pc-linux-gnu/bin/
hubert depesz lubaczewski writes:
On 6/14/06, Sven Geisler
raid 10 is of course not questionable. but are you sure that it will work
faster than for example:
2 discs (raid 1) for xlog
6 discs (raid 10) for tables
6 discs (raid 10) for indices?
Caching up on the performance list.
Although th
On 4-Sep-06, at 8:07 AM, Guillaume Cottenceau wrote:
Dave Cramer writes:
Guillaume
1G is really not a significant amount of memory these days,
Yeah though we have 2G or 4G of RAM in our servers (and not only
postgres running on it).
That said 6-10% of available memory should be given to
"Merlin Moncure" writes:
> On 01 Sep 2006 19:00:52 +0200, Guillaume Cottenceau <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > I've been looking at the results from the pg_statio* tables, to
> > view the impact of increasing the shared buffers to increase
> > performance.
> >
>
> I think 'shared buff
Dave Cramer writes:
> Guillaume
>
> 1G is really not a significant amount of memory these days,
Yeah though we have 2G or 4G of RAM in our servers (and not only
postgres running on it).
> That said 6-10% of available memory should be given to an 8.0 or
> older version of postgresql
>
> Newer
> Hi,
>
> We are seeing hanging queries on Windows 2003 Server SP1 with dual
> CPU, looks like one of the process is blocked. In a lot of cases,
> the whole DB is blocked if this process is holding important locks.
>
> Looks like this issue was discussed in the following thread a few
> month ago,
Hi, Matteo,
Matteo Sgalaberni wrote:
> A my collegue JDBC application that stay in "idle intransaction" 24h/24h
Just a little note: For most applications, this can be fixed updating
the JDBC driver. Old versions had the behaviour of auto-opening a new
backend transaction on commit/rollback, wher
12 matches
Mail list logo
