Re: [Spacewalk-devel] [PATCH] Use braces for accessing composite types in PG
On Friday 02 of November 2012 15:41:25 Johannes Renner wrote: On 10/31/2012 05:00 PM, Tomas Lestach wrote: On Wednesday 31 of October 2012 14:38:49 Johannes Renner wrote: Hey, Ok, here is the patch to make the rewritten query work with PG as well (API call 'system.listLatestUpgradablePackages'). It's actually a follow up to this commit: 4823565b2e634bc73010d366ff82c432630bca85 Committed as: 594781171402e28f85cdcb9fe7e838e35288a505 It was strange though when testing it: for most of my systems it returned really quick (with 0 results though), but I also had one system, where the query did not return at all, even after 1 hour! You might want to do some additional performance testing here. There was nothing special about this specific host though, it was even subscribed to a base channel only.. Can you still reproduce it with that system? I could reproduce it until I cherry-picked your most recent fix from master: 1168f61a9d16b42b533a21513c8538529862e745 The fixed query now runs reasonably fast and delivers results immediately for that specific system. So I'd consider this issue as fixed. Thank you, -- Tomas Lestach RHN Satellite Engineering Thanks, Johannes ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] List of installable packages: API vs. Web UI
On Friday 02 of November 2012 12:03:28 Johannes Renner wrote: On 11/01/2012 01:59 PM, Tomas Lestach wrote: On Wednesday 31 of October 2012 15:00:48 Johannes Renner wrote: Hello, We found that the list of installable packages for a given system differs if you either ask the API (via system.listLatestInstallablePackages) or if you go to the Web UI (Systems - [choose a system] - Software - Packages - Install). After looking into it, I found there is two different queries used for this (both to be found in Package_queries.xml): 1. system_latest_all_available_packages (API) 2. system_available_packages (Web UI) My questions: - Query (1.) seems to return all available versions of a package, which means 'all' rather than 'latest'? I think we could have two separate API calls, one for 'latest' and one for 'all', but 'latest_all'? Right, the naming is strange. - Shouldn't we use the same query for API and Web UI in order to get the same results here? I'd say we do not want to get the same results. As people are used to the WebUI, they may select and install any version of an available package. I wouldn't change that. If an API is called listLatestInstallablePackages, it shall definitelly return list of *latest* installable packages. But what we could do is we can introduce a listAllInstallablePackages/listAvailableInstallablePackages API, that could reuse the WebUI query. :-) Haha, yes, good idea ;-) Hello Johannes, So, IIUC this is the situation summarized: The current API call needs to continue to exist as it is, the method declaration - yes but you agree that the naming of the API call, as well as the query name, is strange. yes To fix this, we would actually rename the existing API call to something more 'correct', like e.g. 'listAllInstallablePackages'. Further we could change the semantics of 'listLatestInstallablePackages' in a way that it reuses the WebUI query and thus will return the same results as the WebUI itself. The only problem is that we are most likely not supposed to change the semantics of an existing API call, right? Is this true, even if we considered such 'unexpected' behavior as a bug? Regards, Johannes If there's a bug in the API call, we of course fix it. But we try to keep the current API interface as is. Spacewalk users have their scripts using our API calls and we do not want to break the scripts by renaming/deleting existing API calls. (Introducing of new sensefull APIs is always good. :) So, it is important that the API behaves according to its name. It the name and behavior do not match, we fix the behavior according to the name and can introduce a new API in case the behavior of the original API was helpfull. However, internal naming has lower priority, because the users do not come into contact with it, so it cannot be confusing for them. (But we of course try to keep the naming sensefull as well.) Regards, -- Tomas Lestach RHN Satellite Engineering ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] I think I found the root cause of the PostgreSQL Idle in transaction connection build up.
Paul Robert Marino prmari...@gmail.com writes: Ive been doing some testing and I am fairly positive I found out why the number of connections in PostgreSQL increases and its not a spacewalk bug at all. It looks like its a JDBC bug [ and is fixed in 8.4-703 ] This is really interesting, but I looked through the upstream commit logs, and I can't see any patches between 8.4-701 and 8.4-703 that look like they'd cure a connection leak such as you're describing. There are a couple of fixes for possible loss-of-protocol-sync issues, but it doesn't seem like that would result in silent leakage; the symptoms would be pretty obvious. Have you poked into the client-side state to see what that end thinks it's doing with the idle connections? regards, tom lane ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] I think I found the root cause of the PostgreSQL Idle in transaction connection build up.
Well you are right there is nothing in the change log that idicates that this issue existed or how its fixed. But as I said it seems to fix it there is probably a side effect fix that was not planed but seems to work. The results are rediculously obvious initialy now honestly I think it needs a few days of testing to prove it, and I would like for others to confirm it but from my initial test it on one of my development instances it looks good. I would like other people to test it because I'm not using monitoring on that instance and I only have a few systems attached to it but the difference is so obvious there is deffinitly something there. By the way I've seen the change log betwean 701to 702 but I haven't seen the change log betwean 702 and 703 and I looked its not on their site or in the source package as far as I could initialy tell. While I admit I can't point to a reason in the change log why, it at least initialy seems to work. I think if any thing it may be a compound correction of multiple bugs that may of fixed a larger harder to pinpoint issue. On Nov 6, 2012 12:01 AM, Tom Lane t...@redhat.com wrote: Paul Robert Marino prmari...@gmail.com writes: Ive been doing some testing and I am fairly positive I found out why the number of connections in PostgreSQL increases and its not a spacewalk bug at all. It looks like its a JDBC bug [ and is fixed in 8.4-703 ] This is really interesting, but I looked through the upstream commit logs, and I can't see any patches between 8.4-701 and 8.4-703 that look like they'd cure a connection leak such as you're describing. There are a couple of fixes for possible loss-of-protocol-sync issues, but it doesn't seem like that would result in silent leakage; the symptoms would be pretty obvious. Have you poked into the client-side state to see what that end thinks it's doing with the idle connections? regards, tom lane ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] I think I found the root cause of the PostgreSQL Idle in transaction connection build up.
On 06.11.2012 06:01, Tom Lane wrote: Paul Robert Marino prmari...@gmail.com writes: Ive been doing some testing and I am fairly positive I found out why the number of connections in PostgreSQL increases and its not a spacewalk bug at all. It looks like its a JDBC bug [ and is fixed in 8.4-703 ] This is really interesting, but I looked through the upstream commit logs, and I can't see any patches between 8.4-701 and 8.4-703 that look like they'd cure a connection leak such as you're describing. There are a couple of fixes for possible loss-of-protocol-sync issues, but it doesn't seem like that would result in silent leakage; the symptoms would be pretty obvious. Have you poked into the client-side state to see what that end thinks it's doing with the idle connections? regards, tom lane Hi, I cannot confirm this. My Idle in transaction connections are all gone since updating to 1.8. The other reported problem concerning hanging update statements was solved by updating psycopgs2 with the patch mentioned in https://bugzilla.redhat.com/show_bug.cgi?id=843723. My connection count is between 50 and 60 idle connections. In general it is working good now. I could also disable by nightly restart of spacewalk and it is running for several days now. Regards Patrick -- Lobster LOGsuite GmbH, Münchner Straße 15a, D-82319 Starnberg HRB 178831, Amtsgericht München Geschäftsführer: Dr. Martin Fischer, Rolf Henrich ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
