Thanks Michael. Sounds like I should just upgrade to 1.7 instead of waiting for 1.8 to be released and see if that helps with the other problems I was seeing, and that 1.8 may resolve the query issue...
Greg Wojtak Sr. Unix Systems Engineer Office: (313) 373-4306 Cell: (734) 718-8472 On 2012-10-04 8:54 AM, "Michael Mraka" <[email protected]> wrote: >Wojtak, Greg (Superfly) wrote: >% Hey there, >% >% I had started setting up a Solaris Spacewalk client and had given up >% because of the seemingly endless stream of issues. I revisited this >% again when I saw there were some newer Solaris packages available. So >... >% [Tue Oct 02 17:39:17 2012] [error] SQLStatementPrepareError: ('syntax >error at or near "name"\\nLINE 3: pn.name name,\\n > ^\\n', 0, '\\n select distinct\\n pn.name >name,\\n pe.epoch epoch,\\n pe.version version,\\n > pe.release release,\\n pa.label arch,\\n >c.label channel_label,\\n nvl2(c.parent_channel, 0, 1) >is_parent_channel\\n from rhnActionPackage ap,\\n >rhnPackage p,\\n rhnPackageName pn,\\n rhnPackageEVR >pe,\\n rhnPackageArch pa,\\n rhnServerChannel sc,\\n > rhnChannelPackage cp,\\n rhnChannel c\\n where >ap.action_id = %(action_id)s\\n and ap.evr_id = p.evr_id\\n >and ap.evr_id = pe.id\\n and ap.name_id = p.name_id\\n and >ap.name_id = pn.id\\n and p.package_arch_id = pa.id\\n and >p.id = cp.package_id\\n and cp.channel_id = sc.channel_id\\n ! >% and sc.server_id = %(server_id)s\\n and sc.channel_id = c.id\\n') >% >% Can someone help me to debug this? I am running solaris client 5.4-7 >% packages against spacewalk 1.6 on centos 6 64-bit with postgres. I >% can upgrade to 1.7, but I didn't want to do it just to see if it fixed >% it (ie, I would if there were enhancements to solaris functionality >% included). > >Hi Greg, > >there was a number of fixes for Solaris support for Spacewalk on >PostgreSQL in 1.7 and nightly. Unfortunately searching for the query >above I can see it's been fixed by commit >8badfd903e32de669796637d80ca4f2156d85f36 in spacewalk-backend-1.8.43-1 >(nightly) so upgrading to 1.7 won't help you at the moment. > >% One other problem I noticed is that when I first register it or ran an >% up2date against an empty channel, it took a very long time (upwards of >% 10 minutes) for the command to complete after the hash marks were >% printed for the client cache operations. Not sure if there is any >% input on that aspect. > >Regards, > >-- >Michael Mráka >Satellite Engineering, Red Hat > > >_______________________________________________ >Spacewalk-list mailing list >[email protected] >https://www.redhat.com/mailman/listinfo/spacewalk-list _______________________________________________ Spacewalk-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/spacewalk-list
