cewalk is the only database I have.
>
>
>Nicole
>
>
>From: spacewalk-list-boun...@redhat.com
> on behalf of Brian Long
>
>Sent: Tuesday, February 27, 2018 10:49 AM
>To: spacewalk-list@redhat.com
>Subject: Re: [Spacewalk-list] postgres DB backup questio
un...@redhat.com on
behalf of Brian Long
Sent: Tuesday, February 27, 2018 10:49 AM
To: spacewalk-list@redhat.com
Subject: Re: [Spacewalk-list] postgres DB backup question
I use the "db-control" program to handle an online (DB running) backup.
db-control online-backup /local/backups/sat
I use the "db-control" program to handle an online (DB running) backup.
db-control online-backup /local/backups/satellite-pgsql.$DATE 1>/dev/null
/Brian/
On Mon, Feb 26, 2018 at 1:23 PM, Nicole Beck wrote:
> Hello!
>
> I’m trying to backup my postgress DB using the Spacewalk install
> documenta
Am 27.02.2018 um 14:37 schrieb Paschedag, Robert:
> This is how I backup my spacewalk db
>
> [...]
Over here we roll like so:
[root@spacewalk ~]# cat /usr/local/bin/spacewalk-db-backup.sh
#!/bin/bash
/usr/bin/spacewalk-dump-schema --to=postgresql | gzip >
/postgresqlbackups/dump-$(date +%s).
e.
Robert
-Ursprüngliche Nachricht-
Von: spacewalk-list-boun...@redhat.com
[mailto:spacewalk-list-boun...@redhat.com] Im Auftrag von Robert Paschedag
Gesendet: Montag, 26. Februar 2018 20:57
An: spacewalk-list@redhat.com; Nicole Beck ;
'spacewalk-list@redhat.com'
Betreff: Re: [Spacewa
Am 26. Februar 2018 19:23:52 MEZ schrieb Nicole Beck :
>Hello!
>I'm trying to backup my postgress DB using the Spacewalk install
>documentation at
>https://github.com/spacewalkproject/spacewalk/wiki/SpacewalkBackup, and
>it fails with the errors below. If I try it without spacewalk running,
>it gi
Hello!
I'm trying to backup my postgress DB using the Spacewalk install documentation
at https://github.com/spacewalkproject/spacewalk/wiki/SpacewalkBackup, and it
fails with the errors below. If I try it without spacewalk running, it gives
an error and creates an empty backup file. If I try it
Hi guys,
Getting these errors:
2017-03-21 00:40:45.403 PDT FATAL: sorry, too many clients already
2017-03-21 00:40:45.749 PDT FATAL: sorry, too many clients already
2017-03-21 00:40:45.750 PDT FATAL: sorry, too many clients already
2017-03-21 00:40:46.437 PDT FATAL: sorry, too many clients alr
Hello!
I'm having same problem while backing up using pg_dumpall, then I ignore
it, the dump progress should be running. And I do second backup for
specific database using pg_dump (eg. rhnschema and postgres).
Then the line should be
$ su - postgres -c 'pg_dump rhnschema > /backup/rhnschema_back
Dear All,
As per link https://fedorahosted.org/spacewalk/wiki/SpacewalkBackup
We can take full backup of DB as below:
#su - postgres -c 'pg_dumpall >
/var/lib/pgsql/backups/full_postgres_backup-`date +%Y%m%d`.sql'
But,I am getting the same error as mentioned in below thread.
https://www.redha
that was a bad idea. I'll wait to get upgraded to 1.9 before jumping in
again. everything was fast but i was getting lots of SQLConnectError FATAL:
sorry, too many clients already
On Wed, May 1, 2013 at 8:58 AM, john miller wrote:
> I have been having a similar issue with 1.7. I applied these p
I have been having a similar issue with 1.7. I applied these patches
(against my better judgement) and the system has went from barely staying
alive to performing better then it has in quite a while. I have about 3k
systems across 9 channels.
On Thu, Mar 14, 2013 at 5:38 AM, Jan Pazdziora wrote:
On Wed, Mar 13, 2013 at 01:08:38PM +, Coffman, Anthony J wrote:
>
> Thanks! This additional patch makes a huge difference.
Thank you for testing and reporting back.
The respun packages were pushed to Spacewalk 1.9 yum repositories
yeterday so yum upgrade (followed by spacewalk-service resta
-list-boun...@redhat.com] On Behalf Of Jan Pazdziora
Sent: Wednesday, March 13, 2013 4:27 AM
To: spacewalk-list@redhat.com
Subject: Re: [Spacewalk-list] Postgres connection issues with Spacewalk 1.9
On Tue, Mar 12, 2013 at 05:52:46PM +, Coffman, Anthony J wrote:
> I applied the patch and reb
On Tue, Mar 12, 2013 at 05:52:46PM +, Coffman, Anthony J wrote:
> I applied the patch and rebooted to start things from a clean slate.
>
> The patch doesn't seem to fix the issue.
>
> The Postgres DB idle connections are still rising to more than 1000 very
> rapidly and staying high even aft
alf Of Coffman, Anthony J
> Sent: Tuesday, March 12, 2013 10:08 AM
> To: spacewalk-list@redhat.com
> Subject: Re: [Spacewalk-list] Postgres connection issues with Spacewalk 1.9
>
> Jan,
>
> Thanks for this. I'll give it a try and report back.
>
> --Tony
>
>
> ---
-boun...@redhat.com] On Behalf Of Coffman, Anthony J
Sent: Tuesday, March 12, 2013 10:08 AM
To: spacewalk-list@redhat.com
Subject: Re: [Spacewalk-list] Postgres connection issues with Spacewalk 1.9
Jan,
Thanks for this. I'll give it a try and report back.
--Tony
-Original Message-
From: spac
t: Re: [Spacewalk-list] Postgres connection issues with Spacewalk 1.9
On Tue, Mar 12, 2013 at 02:24:11PM +0100, Jan Pazdziora wrote:
>
> Could you please apply patch from
>
>
> http://git.fedorahosted.org/cgit/spacewalk.git/commit/?id=00c5e9d460d71c7707393764563e22884
On Mon, Mar 11, 2013 at 03:21:08PM +, Coffman, Anthony J wrote:
> Is anybody else seeing 500 errors on 1.9?
>
> We've had ridiculous numbers (300-400) of Postgres IDLE connections since the
> 1.7 release but it seems they've reach new heights in Spacewalk 1.9. I just
> ran a package refresh
On Tue, Mar 12, 2013 at 02:24:11PM +0100, Jan Pazdziora wrote:
>
> Could you please apply patch from
>
>
> http://git.fedorahosted.org/cgit/spacewalk.git/commit/?id=00c5e9d460d71c7707393764563e228848bef17f
>
> to your driver_postgresql.py to see if it addresses the issue for you?
Afterwa
-list-boun...@redhat.com
[mailto:spacewalk-list-boun...@redhat.com] On Behalf Of Coffman, Anthony J
Sent: Monday, March 11, 2013 1:16 PM
To: spacewalk-list@redhat.com
Subject: Re: [Spacewalk-list] Postgres connection issues with Spacewalk 1.9
Yes - we’ve done several restarts and reboots. Spacewalk _is_
Subject: Re: [Spacewalk-list] Postgres connection issues with Spacewalk 1.9
Have you restarted all the spacewalk services since the update was installed?
-- Sent from my HP Pre3
On Mar 11, 2013 12:48 PM, Coffman, Anthony J wrote:
Sorry for top posting
pg2
python-psycopg2-2.0.14-2.el6.x86_64
Regards,
--Tony
-Original Message-
From: spacewalk-list-boun...@redhat.com [mailto:spacewalk-list-boun...@redhat.com] On Behalf Of Patrick Hurrelmann
Sent: Monday, March 11, 2013 11:39 AM
To: spacewalk-list@redhat.com
Subject: Re: [Spacewalk-list
-list-boun...@redhat.com] On Behalf Of Patrick Hurrelmann
Sent: Monday, March 11, 2013 11:39 AM
To: spacewalk-list@redhat.com
Subject: Re: [Spacewalk-list] Postgres connection issues with Spacewalk 1.9
On 11.03.2013 16:21, Coffman, Anthony J wrote:
> Is anybody else seeing 500 errors on 1.9?
>
> W
On 11.03.2013 16:21, Coffman, Anthony J wrote:
> Is anybody else seeing 500 errors on 1.9?
>
> We've had ridiculous numbers (300-400) of Postgres IDLE connections since the
> 1.7 release but it seems they've reach new heights in Spacewalk 1.9. I just
> ran a package refresh on 30 DEV systems an
Is anybody else seeing 500 errors on 1.9?
We've had ridiculous numbers (300-400) of Postgres IDLE connections since the
1.7 release but it seems they've reach new heights in Spacewalk 1.9. I just
ran a package refresh on 30 DEV systems and the Postgres connection count got
up to around 1000 be
On Mon, Nov 21, 2011 at 10:27:57PM +, Parsons, Aron wrote:
> I did some digging into this query because it is one that is very obviously
> slow when working with real systems.
>
> It seems that the left join to rhnchecksum is the culprit of this slow query.
> Here's the effect on execution
On Mon, 21 Nov 2011, Parsons, Aron wrote:
I did some digging into this query because it is one that is very obviously
slow when working with real systems.
It seems that the left join to rhnchecksum is the culprit of this slow query.
Here's the effect on execution time by changing it to an inn
=0.020..0.021 rows=1 loops=1)
Index Cond: (ci.id = cr.config_info_id)
SubPlan 1
-> Seq Scan on rhnconfigfilename (cost=0.00..1.25 rows=1 width=20)
(never executed)
Filter: (id = $0)
Total runtime: 1.444 ms
(39 rows)
/aron
-
On Mon, 21 Nov 2011, Jan Pazdziora wrote:
On Mon, Nov 21, 2011 at 10:13:38AM +, John Hodrien wrote:
Do you have your database freshly analyzed, by the way?
No. ANALYSE; or is there more to it?
Not sure about ANALYSE but ANALYZE should work. You can do
ANALYZE VERBOSE
to see
On Mon, Nov 21, 2011 at 10:13:38AM +, John Hodrien wrote:
> >
> >Do you have your database freshly analyzed, by the way?
>
> No. ANALYSE; or is there more to it?
Not sure about ANALYSE but ANALYZE should work. You can do
ANALYZE VERBOSE
to see the progress.
--
Jan Pazdziora
Princ
On Mon, 21 Nov 2011, Jan Pazdziora wrote:
On Fri, Nov 04, 2011 at 05:25:25PM +, John Hodrien wrote:
I'm entirely out of my depth on this one, I'll run it past someone else
locally in case that's any help, as I'm not able to contribute a whole lot on
this personally.
Well, the thing did i
On Fri, Nov 04, 2011 at 05:25:25PM +, John Hodrien wrote:
>
> I'm entirely out of my depth on this one, I'll run it past someone else
> locally in case that's any help, as I'm not able to contribute a whole lot on
> this personally.
Well, the thing did improve a bit, even if in very tiny deta
On Fri, 4 Nov 2011, Jan Pazdziora wrote:
spaceschema-#and cf.config_file_name_id =
lookup_config_filename(E'/var/lib/sss/db/cache_default.ldb')
to use index on the rhnConfigFile (cf) table, yet it does not happen:
->
On Thu, Nov 03, 2011 at 03:40:30PM +, John Hodrien wrote:
>
> An example of a query that takes far too long. I'm not in any way a DBA, and
> really do not have a good understanding of postgresql so I'm going to be
> suitably vague here, because I can't really manage anything else.
Actually,
On Thu, 3 Nov 2011, Bo Maryniuk wrote:
On Thu, Nov 03, 2011 at 03:40:30PM +, John Hodrien wrote:
So in pulling out info for a single file, we're doing a join on 1.6 million
rows or am I completely misreading that?
At least the query say so. And also lookup 1.6M times for a file in
/var/li
On Wed, 2 Nov 2011, Gerald wrote:
I'm using spacewalk 1.5/postgres with about 100 hosts.
It's horrible slow with postgres compared to oracle, but with oracle I've
hit the limits of the free Oracle XE edition so
I had to update. I'm not a big oracle fan, but now I'm wishing I had that
performanc
erald
-Ursprüngliche Nachricht-
Von: spacewalk-list-boun...@redhat.com
[mailto:spacewalk-list-boun...@redhat.com] Im Auftrag von John Hodrien
Gesendet: Mittwoch, 02. November 2011 16:10
An: spacewalk-list@redhat.com
Betreff: [Spacewalk-list] Postgres spacewalk
Are people using spacewalk in a
Are people using spacewalk in a decently large setup and finding the
performance passable? I'd previously used SW 1.4 Oracle with about 50 hosts
and found it tolerable, but I'm not finding this with 1.4 or 1.5 with
Postgres.
I installed 1.4 Postgres (later upgraded to 1.5), and the performance i
> Care to file BZ?
It's all ready known and discussed on the list maybe 4 weeks ago ...
After syncing complete CentOS5 i go to the Kickstart Page and click
create new kickstart. Just fill out the 3 pages and you will see an
internal server error. Look's like an sql insert error.
At the Moment i a
On 02/17/2011 02:04 PM, Schugowski, Mario wrote:
> BUT ... generating Kickstarts don't work, so at the moment i can not install
> systems with Spacewalk + PostgreSQL.
Care to file BZ?
--
Miroslav Suchy
Red Hat Satellite Engineering
___
Spacewalk-list
Hello,
well i try to work with 1.4nightly and PostgreSQL. Systems Register - work,
channels work, config managment work mostly. Package upload to channel and
repo-sync work.
BUT ... generating Kickstarts don't work, so at the moment i can not install
systems with Spacewalk + PostgreSQL.
Mit fre
Dne 10.2.2011 16:47, William S. napsal(a):
1.3. I mentioned 1.2 because it seems nothing on PostGres has been
changed since, then. I might have misunderstood.
There was a lot of changes. But I have to admit - not as many as was
from 1.1 to 1.2.
Mirek
> You are still speaking about 1.2, right?
1.3. I mentioned 1.2 because it seems nothing on PostGres has been changed
since, then. I might have misunderstood.
___
Spacewalk-list mailing list
Spacewalk-list@re
Dne 10.2.2011 13:06, Jonathan Hoser napsal(a):
The package loading (rhn_check actions) is still failing, didn't have
the time yet to unriddle that one.
You are still speaking about 1.2, right?
Mirek
___
Spacewalk-list mailing list
Spacewalk-list@re
Didn't get that far -
latest deed was getting rhn_register to work - and actually register the
systems with spacewalk.
The package loading (rhn_check actions) is still failing, didn't have
the time yet to unriddle that one.
Best
-Jonathan
On 02/10/2011 11:27 AM, John Hodrien wrote:
On Thu,
On Thu, 10 Feb 2011, Jonathan Hoser wrote:
Yepp.
I do.
Many many things are not working, (probes, ...) many needed work to get them
running (1.2) -
but! you don't need a fullblown costly Oracle license if you want Fedora13, 14
and Centos repositories with updates as kickstart installs...
Whic
Yepp.
I do.
Many many things are not working, (probes, ...) many needed work to get them
running (1.2) -
but! you don't need a fullblown costly Oracle license if you want Fedora13, 14
and Centos repositories with updates as kickstart installs...
Which is the main reason for me using the Postgre
I realize 1.3 PostGres has the same features as 1.2 but I really want to know
if anyone is using it in a production environment? Its always good to gather
real world system admin feedback :)
Thanks in advance,
Will
_
49 matches
Mail list logo
