On 07/26/2012 09:32 AM, karave...@mail.bg wrote:
Finally I have managed to migrate it in batches of 100-200k user ids and
disconnecting after each query in order to free the backend and leaked
memory.
If you do it in batches, but you do NOT disconnect and reconnect, does
the backend continue to
- Craig Ringer (ring...@ringerc.id.au), на 26.07.2012 в 11:17 -
> On 07/26/2012 09:32 AM, karave...@mail.bg wrote: >> Finally I have
managed to migrate it in batches of 100-200k user ids and >> disconnecting
after each query in order to free the backend and leaked >> memory. > If
you do it
On Jul 26, 2012, at 11:17 AM, Craig Ringer wrote:
> On 07/26/2012 09:32 AM, karave...@mail.bg wrote:
>> Finally I have managed to migrate it in batches of 100-200k user ids and
>> disconnecting after each query in order to free the backend and leaked
>> memory.
> If you do it in batches, but you
Alvaro,
This is indeed the same problem; my apologies for posting a duplicate.
I've checked on two AIXv7.1 servers, one using an xlCv11 runtime, the other
using an xlCv12 runtime.
On the v11 neither mbstowcs_l nor wcstombs_l are defined. On the v12, both
are. So to answer the question posed
Jez Wain writes:
> On the v11 neither mbstowcs_l nor wcstombs_l are defined. On the v12, both
> are. So to answer the question posed on the archive link you provided, the
> assumption made by your configure script appears to be valid. This points to
> there being a problem in the way the pres
On 07/22/2012 02:00 PM, leo xu wrote:
hello everyone:
my pg version is 9.1.2 running on red hat 5.4 x64 servers.one
day,i found all database indexes can't work,reindex database,it can work,but
some table has primary key,found exists the same two records in table.
When did this st
Woah. Your email client did something insane, and I cannot read your
message. See below:
On 07/26/2012 09:37 PM, karave...@mail.bg wrote:
- Craig Ringer (ring...@ringerc.id.au), на 26.07.2012 в 11:17 -
On 07/26/2012 09:32 AM, karave...@mail.bg wrote: >> Finally I have
managed to migra
Hi all
Here's a fully self contained, automated test case that demonstrates the
leak.
Example output on my system, pasted as quote to stop Thunderbird
mangling it:
$ ./hstore-leak-demo.sh
NOTICE: extension "hstore" already exists, skipping
CREATE EXTENSION
DROP TABLE
CREATE TABLE
CREATE T
On 07/26/2012 09:55 PM, luben karavelov wrote:
Ok, I will do the procedure again with taking notes on each step.
Thankyou for taking the time to do this in detail.
First, here are the results of the queries you asked:
count | to_char
-+---
1257262 | 2.26
pg_s
On 07/27/2012 10:30 AM, Craig Ringer wrote:
Hi all
Here's a fully self contained, automated test case that demonstrates
the leak.
Gah. Except it doesn't now, as shown by the text I pasted. WTF?
I was *definitely* seeing this on my system. What's changed?
Will follow up.
--
Sent via pgsql-b
The following bug has been logged on the website:
Bug reference: 6768
Logged by: Fábio Hentz Lunkes
Email address: fabio.lun...@gmail.com
PostgreSQL version: 9.1.0
Operating system: Windows 7
Description:
Hellow.
My teste to developer application with Microssoft Acces
OK, it's certainly leaking, but not in the same drastic way I was able
to reproduce manually a couple of times earlier. Self-contained test
case attached.
$ bash hstore-leak-demo.sh
NOTICE: extension "hstore" already exists, skipping
CREATE EXTENSION
DROP TABLE
CREATE TABLE
CREATE TABLE
INSERT
Craig Ringer writes:
> OK, it's certainly leaking, but not in the same drastic way I was able
> to reproduce manually a couple of times earlier. Self-contained test
> case attached.
Using HEAD with stock parameters, I don't see any significant change in
allocated address space (VSZ): it sits ri
On 07/27/2012 01:47 PM, Tom Lane wrote:
Craig Ringer writes:
OK, it's certainly leaking, but not in the same drastic way I was able
to reproduce manually a couple of times earlier. Self-contained test
case attached.
Using HEAD with stock parameters, I don't see any significant change in
alloca
On 07/27/2012 10:31 AM, Craig Ringer wrote:
Ouch. Sure looks like a leak to me, yeah.
... but it turns out I'm not thinking very straight. I forgot to check
the size of your `shared_buffers' or `work_mem' and forgot to get you to
report `free -m' output after each run to measure _real_ memory
15 matches
Mail list logo
