On Sun, Aug 23, 2009 at 4:48 AM, Craig
Ringer wrote:
> Interestingly, though, the test program does appear to be leaking - at
> least, the peak working set slowly climbs. It's all private working set. Not
> sure why yet since the memory use looks like it _should_ be constant.
How does the return v
Please launch Process Explorer and then your test program. Double-click
on the postgres.exe backends to open info windows for them and do the
same for the test program. Take a screenshot (windows-prtscrn) and save
it. Let the test run a while and do the same thing occasionally to keep
a record.
On 19/08/2009 11:50 PM, Shivesh Wangrungvichaisri wrote:
The following bug has been logged online:
Bug reference: 4996
Logged by: Shivesh Wangrungvichaisri
Email address: s...@appsig.com
PostgreSQL version: 8.3.7
I ran your test program on 8.4.0 (not 8.3.7 as you used), and
On Wed, Aug 19, 2009 at 4:50 PM, Shivesh
Wangrungvichaisri wrote:
> 8) In our real application, since we INSERT a large amount of data per
> query, as well as SELECT a large amount of data per query, the memory leak
> is much worse, and postgres.exe crashes after its memory consumption has
> reache
On 23/08/2009 10:37 AM, Craig Ringer wrote:
On 19/08/2009 11:50 PM, Shivesh Wangrungvichaisri wrote:
Logged by: Shivesh Wangrungvichaisri
Email address: s...@appsig.com
PostgreSQL version: 8.3.7
Operating system: Windows XP x64 / Windows 7 x64
Description: postgres.exe memory consumption keeps
On 19/08/2009 11:50 PM, Shivesh Wangrungvichaisri wrote:
Logged by: Shivesh Wangrungvichaisri
Email address: s...@appsig.com
PostgreSQL version: 8.3.7
Operating system: Windows XP x64 / Windows 7 x64
Description:postgres.exe memory consumption keeps going up
- Examp
2009/8/22 Radoslaw Zielinski :
> $ seq 11 | xargs -ti psql bug -c "select {}, (x).* from (select
> bt_page_items('promocje_pkey',{}) as x ) as y"
> [...]
> psql bug -c select 11, (x).* from (select bt_page_items('promocje_pkey',11)
> as x ) as y
> ERROR: block number out of range
Sorry, I f
2009/8/22 Radoslaw Zielinski :
> bug=# select length(opis_szczeg) from promocje where id = 4300;
> ERROR: missing chunk number 0 for toast value 120741 in pg_toast_29644
Sorry, what datatype is this again? And what encoding?
Perhaps I should have said octet_length() instead of length().
--
On Fri, Aug 21, 2009 at 2:58 PM, Robert Haas wrote:
>
> Maybe you are doing this inside a transaction someplace? If so, it
> won't be visible to other transactions until you commit.
>
but then, if he simply restart the service the transaction will rollback
--
Atentamente,
Jaime Casanova
Soporte
On Fri, Aug 21, 2009 at 04:26:11PM +, Sebastien Lardiere wrote:
>
> The following bug has been logged online:
>
> Bug reference: 5004
> Logged by: Sebastien Lardiere
> Email address: slardi...@hi-media.com
> PostgreSQL version: 8.3.7
> Operating system: Debian Etch
> Desc
Tom Lane [2009-08-21 20:35]:
> Radoslaw Zielinski writes:
>> Greg Stark [2009-08-21 18:55]:
>>> Is this, perchance, new hardware? Did you test the memory in it?
>> It's a "virtual private server"; the hosting provider is swearing
>> everything's fine. I can't vouch for it myself, obviously.
>
Greg Stark [2009-08-21 20:30]:
[...]
> Actually I mean the key for the toast table.
> Let me ask firstly do you get anything if you just do select * from
> pg_toast.pg_toast_29644 where chunk_id = 120741 ?
0 rows.
> And secondly, what do you get if you do "select length(htmlblob) from
> tab whe
12 matches
Mail list logo
