Re: [BUGS] BUG #5756: postgres eat up all memory(2GB memory)
"Amos" This is not a bug. Your PostgreSQL install is misconfigured - you have told it to use more memory than you have. Use a reasonable number of max_connections, maybe as few as 20 or 30, and set c3p0 (your connection pooler) to use one or two fewer than that. Your webapp's clients should share the connections, and you should get MUCH, MUCH better results that way, because your machine will spend less time thrashing and more time getting real work done. Feel free to ask for help on the postgresql-general mailing list if you want further assistance. http://www.postgresql.org/community/lists/ http://archives.postgresql.org/pgsql-general/ -- System & Network Administrator POST Newspapers -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #5756: postgres eat up all memory(2GB memory)
The following bug has been logged online: Bug reference: 5756 Logged by: amos Email address: amosl...@gmail.com PostgreSQL version: 8.3 Operating system: windows server 2008 Description:postgres eat up all memory(2GB memory) Details: Hi: I am sorry for not good at english, so please be patient with what i write, I really need your help,thank you in advance. Current situration: (1)Our server use postgres8.3 database. (2)The server would receive 500-1500 http request, and for each request, server would operate the database once, so may it would use one database connection. (3)then I modify the configuration in "postgresql.conf". What I changed is: (1)max_connections = 2000 (2)shared_buffers = 32MB (3)statement_timeout = 180 //this is 30 minutes So the result is: when the server is working with more than 500 request, the postgres eat up the memory. BTW, our server is running java program, use a database pool whose name is "c3p0". So which configuration should I change to avoid this? Thanks again! -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Problem with ALTER TABLE - occasional "tuple concurrently updated"
On Tue, Nov 16, 2010 at 10:48 AM, Jon Nelson wrote: > I have a process which runs in parallel creating tables which, as the > /final/ step in the import, gets SQL much like the following applied: > > ALTER TABLE foo INHERIT bar; > > Periodically, I get this error: tuple concurrently updated > > Of course, I googled for the error message and see a bunch of issues > involving ANALYZE and even DROP function. > Is this the same root cause? Is there a fix? Is there a lock I could > take or some other approach that would prevent the error? > I thought all ALTER TABLE statements took a big fat lock to prevent > such an issue. The ALTER TABLE generates that error? Is it running concurrently with any other DML? What version of PostgreSQL is this? That does sound like a bug. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5753: Existing Functions No Longer Work
On Tue, Nov 16, 2010 at 5:13 PM, Kris Jurka wrote: > On Tue, 16 Nov 2010, Korry Douglas wrote: > >> Vince - is there any chance that you were using a non-standard PostgreSQL >> distribution or driver before? Like something from EnterpriseDB? It may be >> that a third-party JDBC driver was doing some behind-the-curtains work on >> your behalf. >> > > The stock JDBC driver does have support for refcursors, so that it will do > FETCH ALL FROM it and return a ResultSet object instead of just a string if > you call getObject on a refcursor value. This thread is too confusing with > random snippets, assertions, and differences between pgadmin, psql, and > other interfaces to tell what's really going on. The behavior of the JDBC > driver shouldn't have changed between releases either, but this may explain > the differences seen between pgadmin and the user's application. > > http://jdbc.postgresql.org/documentation/84/callproc.html#callproc-resultset-refcursor This seems likely to be related to the OP's problem, because his code snippet does in fact show him calling getObject()... -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5755: Query Optimzer Bug
On 17.11.2010 18:05, Tom Lane wrote: "Elliott Groszek" writes: The following SQL statements produce different query plans even though "phone" is not reference in the SQL! explain update customer set login_name = (select "NESSOuserName" from person,phone where person.cac_cert=customer.cac_cert); explain update customer set login_name = (select "NESSOuserName" from person where person.cac_cert=customer.cac_cert); That's not a bug. Particularly, note that they produce different results if "phone" table is empty. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5755: Query Optimzer Bug
"Elliott Groszek" writes: > The following SQL statements produce different query plans even though > "phone" is not reference in the SQL! > explain update customer set login_name = > (select "NESSOuserName" from person,phone > where person.cac_cert=customer.cac_cert); > explain update customer set login_name = > (select "NESSOuserName" from person > where person.cac_cert=customer.cac_cert); That's not a bug. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #5755: Query Optimzer Bug
The following bug has been logged online: Bug reference: 5755 Logged by: Elliott Groszek Email address: elliott.gros...@navy.mil PostgreSQL version: 8.4.4 Operating system: RedHat Description:Query Optimzer Bug Details: The following SQL statements produce different query plans even though "phone" is not reference in the SQL! explain update customer set login_name = (select "NESSOuserName" from person,phone where person.cac_cert=customer.cac_cert); explain update customer set login_name = (select "NESSOuserName" from person where person.cac_cert=customer.cac_cert); Please advise, Elliott -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
