[Spacewalk-list] Cloning a large Errata Channel (Fedora 18 Updates)

[Paul Robert Marino]

Check if you had an out of memory error in the PostgreSQL logs usually
in /var/lib/pgsql/data/pg_log depending on your configuration.
If PostgreSQL tries to allocate more memory that the system can give
it will SIG HUP's its self and kills all of the processes that handle
active the connections in the process with a SIG KILL. this would
cause this kind of error. On the bright side if this happens the
PostgreSQL should auto role back any uncommitted transactions as long
as autocommit is turned off.





On Thu, Jun 20, 2013 at 8:22 PM, Jon Miller <jonebird at gmail.com> wrote:
> A bit more information about the error I am seeing. The page, when it
> finally times out, provides a 500 error and generates a traceback email to
> me. If I had to guess, the long running postgres operation failed and rolled
> back and is why Perl code below is complaining about missing postgres
> objects. I poked through /var looking for recently updated logfile and
> didn't find anything to help me with any further clues. The filesystem that
> hold my postgres database has 11G still available and while I wasn't
> watching the disk closely the entire time it was running, I don't believe it
> would eat up 11G of space. The rest of this email is the traceback:
>
> The following exception occurred while executing this request:
>  POST /network/software/channels/manage/edit.pxt HTTP/1.1 (from browser)
>  /network/software/channels/manage/edit.pxt (from Apache)
>
> Date:
>   Thu Jun 20 16:59:12 2013
>
> Headers:
> ...<http headers left out of this email>
> Form variables:
>   channel_arch => 513
>   channel_description =>
>   channel_gpg_key_fp => 7EFB 8811 DD11 E380 B679 FCED FF01 125C DE7F 38BD
>   channel_gpg_key_id => DE7F38BD
>   channel_gpg_key_url => https://fedoraproject.org/static/DE7F38BD.txt
>   channel_name => Neo Fedora 18 Core x86_64 Updates
>   channel_parent => 110
>   channel_summary => Fedora 18 Core x86_64 Updates
>   cid =>
>   clone_from => 134
>   clone_type => current
>   new_channel_label => neo-fedora18-x86_64-updates
>   pxt:trap => rhn:channel_edit_cb
>   submit => Create Channel
>
> User Information:
>   User admin-crad (id 2, org_id 2)
>
> Error notes:
>   (none)
>
> Initial Request:
>   Yes
>
> Error message:
>   RHN::Exception: DBD::Pg::db do failed: ERROR:  no such savepoint
>   RHN::DB /usr/share/perl5/vendor_perl/RHN/DB.pm 121
> RHN::Exception::DB::throw
>   RHN::DB::db /usr/share/perl5/vendor_perl/RHN/DB.pm 185
> RHN::DB::handle_error
>   RHN::DB::db /usr/share/perl5/vendor_perl/RHN/DB.pm 200
> RHN::DB::db::rollback
>   Sniglets::ChannelEditor
> /usr/share/perl5/vendor_perl/Sniglets/ChannelEditor.pm 283
> RHN::DB::db::nested_rollback
>   PXT::ApacheHandler /usr/share/perl5/vendor_perl/PXT/ApacheHandler.pm 482
> Sniglets::ChannelEditor::channel_edit_cb
>   PXT::Request /usr/share/perl5/vendor_perl/PXT/Request.pm 548
> PXT::ApacheHandler::pxt_parse_data
>   PXT::Handlers /usr/share/perl5/vendor_perl/PXT/Handlers.pm 115
> PXT::Request::include
>   PXT::Parser /usr/share/perl5/vendor_perl/PXT/Parser.pm 141
> PXT::Handlers::pxt_include_handler
>   PXT::Parser /usr/share/perl5/vendor_perl/PXT/Parser.pm 72
> PXT::Parser::expand_tag
>   PXT::ApacheHandler /usr/share/perl5/vendor_perl/PXT/ApacheHandler.pm 456
> PXT::Parser::expand_tags
>   PXT::ApacheHandler /usr/share/perl5/vendor_perl/PXT/ApacheHandler.pm 103
> PXT::ApacheHandler::pxt_parse_data
>   PXT::ApacheHandler /usr/share/perl5/vendor_perl/PXT/ApacheHandler.pm 103
> (eval)
>   main -e 0 PXT::ApacheHandler::handler
>   main -e 0 (eval)
>
>
> On Thu, Jun 20, 2013 at 2:47 PM, Jon Miller <jonebird at gmail.com> wrote:
>>
>> I would like to continue to use the same base Fedora 18 channel but clone
>> the Updates channel to be managed independently from the original. (Idea is
>> that separate profiles can use separate Updates channels and manage the
>> updates at their own pace.) When I try cloning the channel from the UI, I
>> end up waiting a very long time just for the request to time out.
>>
>> The updates channel currently has 14,049 packages and while I wait for the
>> update, I notice postgres working hard but I haven't attempted to discover
>> the statement being ran yet.
>>
>> I'm hoping that others have a better / alternative recommendation that I
>> could follow?
>>
>> Thank you,
>> Jon Miller
>
>
>
> _______________________________________________
> Spacewalk-list mailing list
> Spacewalk-list at redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list