On Sat, Mar 30, 2013 at 2:01 PM, wrote:
> uses all available memory (32GB). pts_key is an integer and the table
> contains about 500 million rows.
Please post the schema definition and all the log messages that occur
from this. If it Postgres runs out memory it should include a dump of
the memo
On 30 March 2013 14:01, wrote:
> env CFLAGS='-O3 -march=native' ./configure --with-segsize=128
Why did you build with a segment size of 128GB? Postgres binaries
built with a non-standard segment size are not widely used.
--
Regards,
Peter Geoghegan
--
Sent via pgsql-bugs mailing list (pgsq
unsubscribe
On Sat, Mar 30, 2013 at 8:42 PM, Jeff Lake wrote:
> memory leak with 500 Million rows ??
> sounds like to big of a db
>
> --**---
> -Jeff Lake K8JSL
> MichiganWxSystem.com
> AllisonHouse.com
> TheWeatherCenter.net
> GRLevelXStuff.com
>
stien...@comcast.net writes:
> The query:
> SELECT pts_key,count(*)
> FROM tm_tm_pairs GROUP BY pts_key HAVING count(*) !=1 ORDER BY
> pts_key
> Which is executed as:
> GroupAggregate (cost=108680937.80..119278286.60 rows=470993280 width=4)
>Filter: (count(*) <> 1)
>-> Sort (c
On Sunday, March 31, 2013, Tom Lane wrote:
>
> A different line of thought is that you might have set work_mem to
> an unreasonably large value --- the sort step will happily try to
> consume work_mem worth of memory.
>
I don't think that that can be the problem here, because memtuples can
never
On Sat, Mar 30, 2013 at 8:41 PM, ajmcello wrote:
> unsubscribe
That's not how you unsubscribe from this list; you'll want to do that here:
http://www.postgresql.org/community/lists/subscribe/
--
fdr
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subs
The following bug has been logged on the website:
Bug reference: 8025
Logged by: lindebg
Email address: lind...@gmail.com
PostgreSQL version: 9.2.3
Operating system: Linux 64 bit (Debian, Gentoo), Windows 8 64 bit
Description:
Happened to me a failure of PostgreSQL in
lind...@gmail.com writes:
> I would like to report a minimum combination of SQL, which crashes
> PostgreSQL 64 bit.
Thanks for the test case, will fix.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription
I found that by replacing the postgresql.conf file with the original that is
present following an initdb the query ran without a memory problem. I looked
at the "bad" configuration file and couldn't see anything wrong with it. I
regret that because of a typing error the bad file was accidental
