[BUGS] furiously yours
I've been using postgresql for a quite some time and I have nothing to say about it except it is wonderfull. I recently upgraded to linux redhat 7.1 that had postgresql 7.0.3 on it and started using it. I know I should upgrade to the latest version but since I was behind on time and I'm not using anything fancy, I thought I could just use the version in hand until I get the oportunity to upgrade. Today I noticed (the hard way) after an error came out and caused a big fuss around that the way this version implement ordering is different then the previous version I was using. example new version: BOU MOUSLEH BOUSTANI BOU YAZBEK old version BOU MOUSLEH BOU YAZBECK BOUSTANI it seems that the interpretation differs for the sapce. I would like to know if this was solved in the new version? and if not someone should defenetly do something about it. once again thank you to the developoement team for the inspiring and wonderfull effort you guys are doing. but I realy found this up the hard hard way. thanks, Rony. _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [BUGS] Apparent deadlock for simultaneous sequential scans
Dear Tom, > > > [EMAIL PROTECTED] writes: > > Apparent deadlock for simultaneous sequential scans > > > However, if more than one application is run at once, the performance > > deteriotates drastically. > > So is it a deadlock, or a slowdown? How many is "more than one"? With two processors running the same query, it appears to be a slowdown. When I look at the system calls, the backends were executing about one read per second. With six processors running the same query, it appeared to be a deadlock -- no I/O's were being issued over the time that I watched. "More than one" means two or more. Thanks. --Bob +--++ | Robert E. Bruccoleri, Ph.D. | Phone: 609 737 6383| | President, Congenomics, Inc. | Fax: 609 737 7528| | 114 W Franklin Ave, Suite K1,4,5 | email: [EMAIL PROTECTED]| | P.O. Box 314 | URL: http://www.congen.com/~bruc | | Pennington, NJ 08534 || +--++ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [BUGS] SELECT on VIEW returns wrong result, Buffer Leak
[EMAIL PROTECTED] writes: > CREATE FUNCTION exceptions(int4) RETURNS setof varchar(64) AS ' > SELECT property_id > FROMitm_exception > WHERE item_id = $1 > ' LANGUAGE 'sql'; > CREATE VIEW itm_property_ALL AS > SELECT * > FROMitm_property > WHERE property_id NOT IN (SELECT exceptions(item_id)) > ; Okay ... I get different, but equally wrong, results. The problem is a fundamental shortcoming in the way the Berkeley guys did SQL-functions-returning-sets: the plan inside the function is left running from call to call, and there's no provision for shutting it down if the function is not allowed to run to completion. Since the NOT IN operator stops demanding results once it finds a match, the subselect's function call is left incomplete --- and when the next iteration of the outer query calls the subselect again, you get more of the previous cycle's output, not a fresh run of the function. (The same problem explains the Buffer Leak notices: the last outer query cycle leaves the function still active and holding buffer pins.) This has been a known problem for awhile, and I don't see any nice way to fix it. I don't really want to invest more effort in the Berkeley function-returning-set code anyway; I'd rather rip it out and do something that treats a function returning set as a table source. (That is, you'd do "SELECT ... FROM func(args)".) There are plans to make that happen in the next release or two. In the meantime, I'd suggest writing the view without a function call. regards, tom lane ---(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] Apparent deadlock for simultaneous sequential scans
[EMAIL PROTECTED] (Robert E. Bruccoleri) writes: > With two processors running the same query, it appears to be a > slowdown. When I look at the system calls, the backends were > executing about one read per second. With six processors running the > same query, it appeared to be a deadlock -- no I/O's were being issued > over the time that I watched. It's hard to believe there's an actual deadlock here. You might be looking at pathological inefficiency of the spinlock implementation, but still it seems that someone somewhere must be getting some work done. Can you determine which backend actually has the spinlock? What's it doing? Given that you mentioned you had a large number of shared buffers, it might be that a background checkpoint process running BufferSync() is part of the problem. It looks like BufferSync acquires the spinlock separately for each buffer it examines, which would be kinda nasty in the presence of heavy contention. OTOH we shouldn't really care if BufferSync is slow. regards, tom lane ---(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] Re: [GENERAL] REPOST: redefining location of the socket file /tmp/.s.PGSQL.5432
Arcady Genkin <[EMAIL PROTECTED]> writes: > Can I redefine location of the UNIX domain socket file to be other > than /tmp/.s.PGSQL.5432? Yes, in 7.1 this is a supported option. See unix_socket_directory parameter. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
