[BUGS] BUG #1747: PostgreSQL 'hangs' after prolonged usage
The following bug has been logged online: Bug reference: 1747 Logged by: Wojciech Sobczuk Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0.3 Operating system: FreeBSD 5.4-RELEASE Description:PostgreSQL 'hangs' after prolonged usage Details: Hello, I have a very busy dual-RAID1 machine, doing tens up to hundreds of queries per second. After around 6 days of running at that kind of a load postgresql starts processing queries very very slowly (load jumps to 40 from 2) which brings my system to it's knees. The only thing which helps then is hard-restarting postgresql - and then it works fine for another 6 days. Rebooting the machine has no influence on the performance so it seems to be a postgresql issue. My database takes up 9GB on the hdd and has millions of rows in around 40 relations (4-5 are really large, the rest is small). I use a bit of triggers, but besides that it's just standard SQL queries (called from Java using the 8.0 JDBC driver). Please let me know if you're able to reproduce this bug - you just need to put postgresql at a very high load for a long time (that's my first guess, I don't have an enviroment in which I could do such tests, and even if I did I woudln't know what to look for). Any ideas how to fix it? Thanks ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[BUGS] BUG #1746: libpq/libpq-fs.h not included in distribution
The following bug has been logged online: Bug reference: 1746 Logged by: Lance Clifner Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0.3 Operating system: Windows Description:libpq/libpq-fs.h not included in distribution Details: I started to implement large objects with libpq. The sample code shows that I need to include libpq/libpq-fs.h. This file was not included in the distribution (the entire libpq subdirectory is missing--in case there are other files in it). ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [BUGS] BUG #1747: PostgreSQL 'hangs' after prolonged usage
On Sat, Jul 02, 2005 at 02:12:42PM +0100, Wojciech Sobczuk wrote: > I have a very busy dual-RAID1 machine, doing tens up to hundreds of queries > per second. After around 6 days of running at that kind of a load > postgresql starts processing queries very very slowly (load jumps to 40 from > 2) which brings my system to it's knees. The only thing which helps then is > hard-restarting postgresql - and then it works fine for another 6 days. > Rebooting the machine has no influence on the performance so it seems to be > a postgresql issue. Erm, what about vacuum? What kind of queries? explain analyze of such "slow" query might help a lot to find a reason. p. -- Paweł Bernat; uselessness' lover; select''as email; Slowly and surely the unix crept up on the Nintendo user ... ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [BUGS] BUG #1747: PostgreSQL 'hangs' after prolonged usage
"Wojciech Sobczuk" <[EMAIL PROTECTED]> writes: > Please let me know if you're able to reproduce this bug - you just need to > put postgresql at a very high load for a long time No, otherwise we'd have heard a lot more complaints than yours. You'll need to provide sufficient information to let someone else reproduce the problem. This report is not even a start at that. I would suggest doing some investigation to determine why things get slower --- eg, is the system starting to swap heavily? Watching top, vmstat, pg_stat_activity, etc would probably be informative. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] BUG #1747: PostgreSQL 'hangs' after prolonged usage
"Wojciech Sobczuk" <[EMAIL PROTECTED]> writes: > The only thing which helps then is > hard-restarting postgresql - and then it works fine for another 6 days. > Rebooting the machine has no influence on the performance so it seems to be > a postgresql issue. BTW, exactly what do you mean by "hard-restarting postgresql"? A machine reboot would certainly include a postmaster restart, so you seem to be using that term to mean something else than what most of us would consider it to mean. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [BUGS] BUG #1736: endless loop in PQconnectdb
Karsten Desler wrote: > * Karsten Desler wrote: > > * Bruce Momjian wrote: > > > Yes, please --- the patch is at: > > > > > > http://archives.postgresql.org/pgsql-patches/2005-06/msg00486.php > > > > Thanks. > > I've applied the patch now, and I'll keep you posted. > > It doesn't seem to have helped, and while poking around a little, I > found another annoyance. libpq seems to leak memory if I pass a dns name as > host in conninfo. It doesn't leak when I do the getaddrinfo myself and pass > an IP. > > root 16580 0.0 0.2 4004 1304 ?S10:07 0:00 monitor > xxx.xxx.xxx.xxx > root 22434 0.0 1.9 47328 9240 ?SJun07 5:42 monitor > xxx.xxx.xxx.yyy > > ==9980== 4648 bytes in 166 blocks are definitely lost in loss record 4 of 4 > ==9980==at 0x1B90459D: malloc (vg_replace_malloc.c:130) > ==9980==by 0x1BC39E3B: (within /lib/tls/i686/cmov/libresolv-2.3.2.so) > ==9980==by 0x1BC38B92: __libc_res_nquery (in > /lib/tls/i686/cmov/libresolv-2.3.2.so) > ==9980==by 0x1BC39289: (within /lib/tls/i686/cmov/libresolv-2.3.2.so) > ==9980==by 0x1BC38E8F: __libc_res_nsearch (in > /lib/tls/i686/cmov/libresolv-2.3.2.so) > ==9980==by 0x1BDA907D: ??? > ==9980==by 0x1B9F0A65: (within /lib/tls/i686/cmov/libc-2.3.2.so) > ==9980==by 0x1B9F1673: getaddrinfo (in /lib/tls/i686/cmov/libc-2.3.2.so) > ==9980==by 0x1B9259A1: getaddrinfo_all (in /usr/lib/libpq.so.3.1) > ==9980==by 0x1B916F3B: (within /usr/lib/libpq.so.3.1) > ==9980==by 0x1B9164E9: PQconnectStart (in /usr/lib/libpq.so.3.1) > ==9980==by 0x1B916471: PQconnectdb (in /usr/lib/libpq.so.3.1) I think what you are seeing is that the getaddrinfo memory is placed in the PGconn structure that isn't freed until PQclear is called. Does your test call PQclear()? -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[BUGS] BUG #1748: Unique contraints cannot be added to long text fields
The following bug has been logged online: Bug reference: 1748 Logged by: Greg Steffensen Email address: [EMAIL PROTECTED] PostgreSQL version: 8.02 Operating system: Gentoo Linux Description:Unique contraints cannot be added to long text fields Details: I'm storing SVG files, which can be many kilobytes long, in a text field. When I try to add a unique contraint to that field, or try to add a row to a table that already has had the unique contraint applied, I get errors like the following: ERROR: index row requires 15528 bytes, maximum size is 8191 Evidently, the unique constraint creates an index, but the index can't handle large field sizes. ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
