From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
Cc: | Greg Stark <stark(at)mit(dot)edu>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Odd out of memory problem. |
Date: | 2012-03-26 17:23:58 |
Message-ID: | 4F70A62E.9030403@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 03/26/2012 01:06 PM, Heikki Linnakangas wrote:
> On 26.03.2012 19:59, Heikki Linnakangas wrote:
>> On 26.03.2012 19:51, Greg Stark wrote:
>>> On Mon, Mar 26, 2012 at 5:41 PM, Andrew Dunstan<andrew(at)dunslane(dot)net>
>>> wrote:
>>>> Combo CIDs: 755490840 total in 100 blocks; 5161072 free (381
>>>> chunks); 750329768 used
>>>
>>> I think you'll have to catch Heikki's attention to get a good answer
>>> to this.
>>>
>>> Is it possible this job is inserting and then updating (or deleteing)
>>> the row it just inserted and doing a large number of such
>>> insert/update operations all within the same transaction? Or perhaps
>>> it's updating the same row over and over again?
>>
>> .. and all that in different subtransactions.
>
> sorry, scratch that, they don't need to be in different subtransactions.
It's all in a single transaction. In fact the solution I'm currently
testing and seems to be working involves breaking it up into batches of
a few thousand LOs restored per batch.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2012-03-26 17:34:52 | Re: Odd out of memory problem. |
Previous Message | Tom Lane | 2012-03-26 17:15:47 | Re: Odd out of memory problem. |