Re: [pgadmin-support] pgadmin 1.6.3 - segmentation fault
Marcin Zajączkowski wrote: Hi, Sometimes (but rarer that 1.4) my pgadmin catches segmentation fault when I want to close "edit grid" window. Last time I ran it from gdb (stack trace below). It's pgadmin 1.6.3 (rev. 6115) recompiled from SRPM for FC7 (with also recompiled wxWidgets 2.8.3). I have Fedora Core 6. Can you reproduce this in a recent snapshot? Regards, Dave ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[pgadmin-support] pg_dump: Exclude multiple tables in version 7.4
Hi All, I want to dump the database by using pg_dump command but the problem is the version at the server is 7.4 which doesn't support the provision for excluding tables as in version 8.2. There are 500+ tables in the database,from which 15-20 are of huge sizes.I want to exclude them.Is there any way to do it? I knw that I have to use include instead of excluding the tables.Do I have to include each and every tables manually or is there way to do that? Do i have to write the script for this? if yes, how should I proceed? Please help me out with this issue. Thanks in Advance. Cheers, Cha -- View this message in context: http://www.nabble.com/pg_dump%3A-Exclude-multiple-tables-in-version-7.4-tf3944401.html#a11188792 Sent from the PostgreSQL - pgadmin support mailing list archive at Nabble.com. ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [pgadmin-support] PgAgent output
[please keep replies on list] Eric Shuman wrote: Hi Dave, Thanks for the reply. Typically I do run it from an init script. In this case the output just goes to the login screen of the physical server, which is not too big of a deal since I rarely use the system that way. (Though it would be nice to keep that screen uncluttered as well) The problem mostly arises during testing when I have started pgAgent manually, and still try to use that terminal session to do more work. I don't get any output to the screen while pgAgent is sleeping, but as soon as a job starts to run I will get output. Nothing gets written to the created log file. If you increase the log level to 2, you should see the scheduler activity, eg: DEBUG: Checking for jobs to run DEBUG: Sleeping... DEBUG: Clearing inactive connections DEBUG: Connection stats: total - 1, free - 0, deleted - 0 Does that go to the logfile, or the terminal? Also, what sort of jobs are you running; shell, or SQL? If the former, is it just failing to capure one of the standard output streams for example? Can you create a test script that outputs to both stderr and stdout and see if one of both fail to get captured? If it's an SQL job, what are you seeing in the output? Is it the normal command tags etc. that PostgreSQL outputs, or vacuum output etc? I guess I could just redirect stdout & stderr to /dev/null or some file. Yeah, but I'd rather find out why it's not working for you. Regards, Dave. ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [pgadmin-support] pgadmin 1.6.3 - segmentation fault
On 2007-06-19 09:25, Dave Page wrote: Marcin Zajączkowski wrote: Sometimes (but rarer that 1.4) my pgadmin catches segmentation fault when I want to close "edit grid" window. Last time I ran it from gdb (stack trace below). It's pgadmin 1.6.3 (rev. 6115) recompiled from SRPM for FC7 (with also recompiled wxWidgets 2.8.3). I have Fedora Core 6. Can you reproduce this in a recent snapshot? I have a problem with its (and 20070618 as well) compilation (installation): /home/marcinz/rpmbuild/BUILD/pgadmin3-1.7.0/config/install-sh -c -m 644 './docs/zh_TW/hints/vacuum.html' '/var/tmp/pgadmin3-1.6.3.20070619-1.fc6-root-marcinz/usr/share/pgadmin3/docs/zh_TW/hints/vacuum.html' /home/marcinz/rpmbuild/BUILD/pgadmin3-1.7.0/config/install-sh -c -m 644 './docs/zh_TW/hints/view-without-pk.html' '/var/tmp/pgadmin3-1.6.3.20070619-1.fc6-root-marcinz/usr/share/pgadmin3/docs/zh_TW/hints/view-without-pk.html' make[2]: Leaving directory `/home/marcinz/rpmbuild/BUILD/pgadmin3-1.7.0' make[1]: Leaving directory `/home/marcinz/rpmbuild/BUILD/pgadmin3-1.7.0' + cp -f ./src/include/images/elephant48.xpm /var/tmp/pgadmin3-1.6.3.20070619-1.fc6-root-marcinz//usr/share/pgadmin3/pgadmin3.xpm cp: cannot stat `./src/include/images/elephant48.xpm': No such file or directory Were there some changes with graphic files? Regards Marcin ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [pgadmin-support] pgadmin 1.6.3 - segmentation fault
Marcin Zajączkowski wrote:
cp: cannot stat `./src/include/images/elephant48.xpm': No such file or
directory
Were there some changes with graphic files?
Yeah, in fact the entire src/ tree moved to pgadmin/.
In the spec file, change the line:
cp -f ./src/include/images/elephant48.xpm
%{buildroot}/%{_datadir}/%{name}/%{name}.xpm
to
cp -f ./pgadmin/include/images/elephant48.xpm
%{buildroot}/%{_datadir}/%{name}/%{name}.xpm
And that should fix it. I've made the change in SVN already.
Regards, Dave.
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
[pgadmin-support] Debian Etch packaging problem?
Regarding pgadmin3-data File on mirror(s) = 2722978 bytes Size in "Packages"/apt-cache show = 2722412 Obviously this causes an error: Failed to fetch ftp://ftp2.uk.postgresql.org/sites/ftp.postgresql.org/pgadmin3/release/debian/dists/etch/pgadmin/binary-all/misc/pgadmin3-data_1.6.3-1~pgaoetch1_all.deb Size mismatch E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing? Have checked a German mirror too, and confirmed it's not just UK#2 with that filesize. I'm upgrading from 1.6.2-1~pgaoetch1 though I don't think it's relevant. -- Richard Huxton Archonet Ltd ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[pgadmin-support] Debian Etch (4.0 stable) package problem
I'm getting errors upgrading from 1.6.2-1~pgaoetch1 to 1.6.3-1~pgaoetch1 via the UK mirror ftp2.uk.postgresql.org Get: 1 ftp://ftp2.uk.postgresql.org etch/pgadmin pgadmin3 1.6.3-1~pgaoetch1 [4330kB] Get: 2 ftp://ftp2.uk.postgresql.org etch/pgadmin pgadmin3-data 1.6.3-1~pgaoetch1 [2722kB] Fetched 7053kB in 56s (124kB/s) Failed to fetch ftp://ftp2.uk.postgresql.org/sites/ftp.postgresql.org/pgadmin3/release/debian/dists/etch/pgadmin/binary-all/misc/pgadmin3-data_1.6.3-1~pgaoetch1_all.deb Size mismatch E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing? Checking the download: ls -l /var/cache/apt/archives/partial/ total 2664 -rw-r--r-- 1 root root 2722978 2007-05-24 19:24 pgadmin3-data_1.6.3-1~pgaoetch1_all.deb This appears to match the size on the server. The reported size in "Packages" and as reported by "apt-cache show" is 2722412 Packaging issue? -- Richard Huxton Archonet Ltd ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re : [pgadmin-support] pg_dump: ALTER SEQUENCE ... OWNED in 8.1
OK, I understand that. May be that's a pg_dump issue: it should be compatible with the server it connects to, and not to its own version ? Still meanwhile I would think pgAdmin should allow installing other pg_dump executable. And it should switch from one to another to be able to generate a correct code, according to the server used. There could be different installer: one with only the latest tools and another one with all compatible tools versions to be able to work correctly on different servers ! Have fun, [EMAIL PROTECTED] The Computing Froggy - Message d'origine De : Guillaume Lelarge <[EMAIL PROTECTED]> À : [EMAIL PROTECTED] Cc : Laurent ROCHE <[EMAIL PROTECTED]>; pgadmin-support@postgresql.org Envoyé le : Lundi, 18 Juin 2007, 23h53mn 13s Objet : Re: [pgadmin-support] pg_dump: ALTER SEQUENCE ... OWNED in 8.1 Raymond O'Donnell a écrit : > On 18/06/2007 17:50, Laurent ROCHE wrote: > >> However my server is PG 8.1 and this is 8.2 syntax. I understand >> pgAdmin runs a standard pg_dump but I would expect it to run a >> version compatible with my server ! ? ! > > I run the Windows version of pgAdmin, and the installer bundles the > latest version of pg_dump available at the time of release - so this > would have been 8.2 with the current pgAdmin. > That's right. And bundling some releases has a cost. pgAdmin's package would be much more heavy. One way we could try is to put the other pg_dump releases on other packages and let the user chooses which one he wants to use. But, GUI won't be easy. At least, you can try with a 8.1 pg_dump release. (please, be sure to copy your existing pg_dump before anything). Regards. -- Guillaume. _ Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: Re : [pgadmin-support] pg_dump: ALTER SEQUENCE ... OWNED in 8.1
On 19/06/2007 13:54, Laurent ROCHE wrote: May be that's a pg_dump issue: it should be compatible with the server it connects to, and not to its own version ? What do you mean? Still meanwhile I would think pgAdmin should allow installing other pg_dump executable. I'm fairly sure that pgAdmin will work with whatever pg_dump you have handy. And it should switch from one to another to be able to generate a correct code, according to the server used. Agreed - an option in the preferences to specify the path to the desired pg_dump would certainly be useful. There could be different installer: one with only the latest tools and another one with all compatible tools versions to be able to work correctly on different servers ! The installer guys are going to *love* that suggestion! :-) Ray. --- Raymond O'Donnell, Director of Music, Galway Cathedral, Ireland [EMAIL PROTECTED] --- ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: Re : [pgadmin-support] pg_dump: ALTER SEQUENCE ... OWNED in 8.1
Raymond O'Donnell wrote: > On 19/06/2007 13:54, Laurent ROCHE wrote: > >> May be that's a pg_dump issue: it should be compatible with the >> server it connects to, and not to its own version ? > > What do you mean? Shipping every version of pg_dump, libpq & supporting DLL's back to v7.3 by the sound of it! >> Still meanwhile I would think pgAdmin should allow installing other >> pg_dump executable. > > I'm fairly sure that pgAdmin will work with whatever pg_dump you have > handy. It will. >> And it should switch from one to another to be able to generate >> a correct code, according to the server used. > > Agreed - an option in the preferences to specify the path to the desired > pg_dump would certainly be useful. Already in the next release. >> There could be different installer: one with only the latest tools and >> another one with all compatible tools versions to be able to work >> correctly on different servers ! > > The installer guys are going to *love* that suggestion! :-) That simply isn't gonna happen. /D ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: Re : [pgadmin-support] pg_dump: ALTER SEQUENCE ... OWNED in 8.1
On 19/06/2007 14:36, Dave Page wrote: Raymond O'Donnell wrote: Agreed - an option in the preferences to specify the path to the desired pg_dump would certainly be useful. Already in the next release. Great! another one with all compatible tools versions to be able to work correctly on different servers ! The installer guys are going to *love* that suggestion! :-) That simply isn't gonna happen. I wouldn't imagine it was a serious suggestion in the first place. :-) Anyway, the other change (above) should take care of the needs of anyone who has to juggle multiple pg_dump versions. Ray. --- Raymond O'Donnell, Director of Music, Galway Cathedral, Ireland [EMAIL PROTECTED] --- ---(end of broadcast)--- TIP 1: 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: [pgadmin-support] pg_dump: Exclude multiple tables in version 7.4
>I knw that I have to use include instead of excluding the tables.Do I have to include each and >>every tables manually or is there way to do that? There's no guarantee. but the following query might be a good starting point to build your include list. It selects only tables with less than 3000 tuples (naturally you will change the value to suit your needs. Note that per the documenatation: "This is only an estimate used by the planner. It is updated by VACUUM, ANALYZE, and a few DDL commands such as CREATE INDEX." So a FULL VACUUM is advised before executing. SELECT n.nspname || ' .' || c.relname AS tablename FROM pg_class c LEFT JOIN pg_namespace n ON n.oid = c.relnamespace LEFT JOIN pg_tablespace t ON t.oid = c.reltablespace WHERE c.relkind = 'r'::"char" AND reltuples < 3000 ORDER BY n.nspname; Melvin Davidson Database Developer Computer & Communication Technologies, Inc. 6 Inverness Court East, Suite 220 Englewood, CO 80112 BEGIN:VCARD VERSION:2.1 N:Davidson;Melvin FN:Melvin Davidson ORG:CCT TEL;WORK;VOICE:303-708-9228x305 ADR;WORK;ENCODING=QUOTED-PRINTABLE:;;6 Inverness Ct East=0D=0ASuite 220;Englewood;CO;80112;United States LABEL;WORK;ENCODING=QUOTED-PRINTABLE:6 Inverness Ct East=0D=0ASuite 220=0D=0AEnglewood, CO 80112=0D=0AUnited Stat= es EMAIL;PREF;INTERNET:[EMAIL PROTECTED] REV:20060518T221645Z END:VCARD ---(end of broadcast)--- TIP 1: 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: [pgadmin-support] pgadmin 1.6.3 - segmentation fault
On 2007-06-19 10:29, Dave Page wrote:
(...)
cp -f ./pgadmin/include/images/elephant48.xpm
%{buildroot}/%{_datadir}/%{name}/%{name}.xpm
And that should fix it. I've made the change in SVN already.
And it did it. In fact firstly I thought it was problem with your
makefile not with spec.
I already work on a snapshot and I'll let you know if a crash happens
(but it can take some time, it's not 1.4.x ;) ).
Regards
Marcin
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Using many pg_dump in pgAdmin (aka Re : Re : [pgadmin-support] pg_dump: ALTER SEQUENCE ... OWNED in 8.1)
Hi, Just to clarify what I mean. I am quite happy (or should I say: not too unhappy) to juggle with different version of pg_dump in my scripts. If that's the way it has to be, that's the way it has to be. See point A, below. But to me pgAdmin is a tool that must be easy to use. Hence, as it seems the rule of pg_dump usage is "if I connect to 8.1 server, I must use pg_dump 8.1; if I connect to a 8.2 server, I must use a 8.2 server; ...". There should be an option for doing that automatically: I should not need to switch from a pg_dump to another when I switch servers. So what I have in mind is: - default installation: use pgAdmin pg_dump - activate multi-pg_dump mode: give a directory where there's a tree with a directory for each server version used. And each directory contains the matching (to the directory name) pg_dump version. This way, the standard install is the same. But if I need to connect to different servers with different versions, I don't need to keep switching from one pg_dump to another all the time: pgAdmin will do it for me. I understand that's quite a lot of work to be done, but on a user perspective, that's the painless of doing it ... well, at least on my humble opinion, but I assume other users might have other views on the subject. Have fun, [EMAIL PROTECTED] The Computing Froggy - Message d'origine >>> May be that's a pg_dump issue: it should be compatible with the >>> server it connects to, and not to its own version ? > >> What do you mean? >Shipping every version of pg_dump, libpq & supporting DLL's back to v7.3 >by the sound of it! ** Point A ** Nope, just that pg_dump should generate code compatible with the server it connects too. I was told once on the PG list that pg_dump aim is to be able to backup and restore, with the newer version of the tool, that does not work on an older server. ___ Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses http://fr.answers.yahoo.com ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: Using many pg_dump in pgAdmin (aka Re : Re : [pgadmin-support] pg_dump: ALTER SEQUENCE ... OWNED in 8.1)
Laurent ROCHE a écrit : > Just to clarify what I mean. > I am quite happy (or should I say: not too unhappy) to juggle with different > version of pg_dump in my scripts. > If that's the way it has to be, that's the way it has to be. > See point A, below. > > But to me pgAdmin is a tool that must be easy to use. > Hence, as it seems the rule of pg_dump usage is "if I connect to 8.1 server, > I must use pg_dump 8.1; if I connect to a 8.2 server, I must use a 8.2 > server; ...". There should be an option for doing that automatically: I > should not need to switch from a pg_dump to another when I switch servers. > That's not strictly right. If you want a backup, you also want to restore it. And this is the real question. On which release do you want to restore it ? you can dump a 7.4 database with a 8.0 pg_dump and you will probably be able to restore it on a 8.2 database. But there's good chance you won't be able to restore it on a 7.4 database. Why ? Just because each new release adds new syntax specifics that older releases don't understand. So, it's better to have the same release on the restored database and the pg_dump. You can use an older release, there's a good chance it will work. You can (try to) restore it on an older release, but you'll need luck to restore it succesfully. > So what I have in mind is: > - default installation: use pgAdmin pg_dump > - activate multi-pg_dump mode: give a directory where there's a tree with a > directory for each server version used. And each directory contains the > matching (to the directory name) pg_dump version. > This is not so easy. You don't choose pg_dump on the release of the saved database, but on the restored one. > This way, the standard install is the same. > But if I need to connect to different servers with different versions, I > don't need to keep switching from one pg_dump to another all the time: > pgAdmin will do it for me. > I understand that's quite a lot of work to be done, but on a user > perspective, that's the painless of doing it ... well, at least on my humble > opinion, but I assume other users might have other views on the subject. > I agree pgAdmin should let the users choose the pg_dump binary they want, but unfortunately, pgAdmin can't say which release will be the good one. I'm sorry, I'm sure my english is really bad this time. Perhaps Dave can explain a bit better than I did. Regards. -- Guillaume. ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: Using many pg_dump in pgAdmin (aka Re : Re : [pgadmin-support]p g_dump: ALTER SEQUENCE ... OWNED in 8.1)
> --- Original Message --- > From: Guillaume Lelarge <[EMAIL PROTECTED]> > To: Laurent ROCHE <[EMAIL PROTECTED]> > Sent: 19/06/07, 17:33:02 > Subject: Re: Using many pg_dump in pgAdmin (aka Re : Re : > [pgadmin-support]pg_dump: ALTER SEQUENCE ... OWNED in 8.1) > > Laurent ROCHE a écrit : > > Just to clarify what I mean. > > I am quite happy (or should I say: not too unhappy) to juggle with > > different version of pg_dump in my scripts. > > If that's the way it has to be, that's the way it has to be. > > See point A, below. > > > > But to me pgAdmin is a tool that must be easy to use. > > Hence, as it seems the rule of pg_dump usage is "if I connect to 8.1 > > server, I must use pg_dump 8.1; if I connect to a 8.2 server, I must use a > > 8.2 server; ...". There should be an option for doing that automatically: I > > should not need to switch from a pg_dump to another when I switch servers. > > > > That's not strictly right. > > If you want a backup, you also want to restore it. And this is the real > question. On which release do you want to restore it ? you can dump a > 7.4 database with a 8.0 pg_dump and you will probably be able to restore > it on a 8.2 database. But there's good chance you won't be able to > restore it on a 7.4 database. > > Why ? Just because each new release adds new syntax specifics that older > releases don't understand. The recommended method is to always dump using the pg_dump from the version of PostgreSQL you will be restoring to - that way the dump is written in the most appropriate format. > So, it's better to have the same release on the restored database and > the pg_dump. You can use an older release, there's a good chance it will > work. You can (try to) restore it on an older release, but you'll need > luck to restore it succesfully. Yup. > I agree pgAdmin should let the users choose the pg_dump binary they > want, but unfortunately, pgAdmin can't say which release will be the > good one. Exactly. > I'm sorry, I'm sure my english is really bad this time. Perhaps Dave can > explain a bit better than I did. Your explanation is fine. /D ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
