pg_dump - segfault with -z option
hi.
I hope this is not a rehash of anything; a quick look at the mailing list
archives turned up similar, but not identical stories.
When I use the "-z" option (dump permissions)when dumping a database I have, I
get a segfault and no output. The other options are irrelevant (i.e., I can
specify any other option or options I like, it still happens). To the best of
my knowledge I have nothing tricky or complex in my database, just standard
types like varchar, bool and int, the refint stuff and a trigger or two.
It does NOT segfault with template1, but nor do I get any output, maybe this
is normal, I'm a total novice at this :-)
This is not a critical issue for me, I can always set the permissions on my
tables manually, but a) it would be nice not to have to and b) I thought it
might interest someone... Seems to me that whatever the reasons for it,
pg_dump should not lose it to the extent of segfaulting :-)
Regards, K.
---
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer (auer@kom.id.ethz.ch) Geschaeft/work +41-1-6327531
Kommunikation, ETHZ RZ Privat/home +41-1-4517941
Clausiusstrasse 59 Fax +41-1-6321225
CH-8092 ZUERICH Switzerland
[Charset iso-8859-1 unsupported, filtering to ASCII...]
hi.
I hope this is not a rehash of anything; a quick look at the mailing list
archives turned up similar, but not identical stories.When I use the "-z" option (dump permissions)when dumping a database I have, I
get a segfault and no output. The other options are irrelevant (i.e., I can
specify any other option or options I like, it still happens). To the best of
my knowledge I have nothing tricky or complex in my database, just standard
types like varchar, bool and int, the refint stuff and a trigger or two.It does NOT segfault with template1, but nor do I get any output, maybe this
is normal, I'm a total novice at this :-)This is not a critical issue for me, I can always set the permissions on my
tables manually, but a) it would be nice not to have to and b) I thought it
might interest someone... Seems to me that whatever the reasons for it,
pg_dump should not lose it to the extent of segfaulting :-)
I believe this will be fixed in the first 6.4 minor release. Should we
schedule 6.4.1 soon, folks.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
Karl Auer <auer@kom.id.ethz.ch> writes:
When I use the "-z" option (dump permissions)when dumping a database I
have, I get a segfault and no output.
Are you on Postgres 6.4? I recall fixing several nasty problems with
permissions in pg_dump between 6.3.2 and 6.4.
If you are on 6.4, could you use gdb or something to get a backtrace
showing exactly where pg_dump dies?
FWIW, I currently use -z routinely, but my database is probably even
simpler than yours ... no triggers, for example. My guess is pg_dump
doesn't work for permissions attached to a trigger, or something along
that line.
regards, tom lane
Import Notes
Reply to msg id not found: YourmessageofTue24Nov1998164943+0100XFMail.981124164943.auer@kom.id.ethz.ch | Resolved by subject fallback
Thanks Tom.
Yes, I am on 6.4. As to gdb, I really wouldn't know how to get the info you
request. The segfault doesn't result in a core file either.
There is nothing sacred about my project (supporting RADIUS authentication),
I'll happily send you my database creation scripts if you want to try making
this happen yourself. This is 6.4 as stated, running on a SuSE 5.3 (Linux
2.0.34) distribution. No problems running the database and all the build
tests work fine.
I have no permissions attached to triggers as far as I know; and the
permissions aren't complicated either. The segfault occurs when running the
dump as user postgres, which should have godlike permissions anyway...
Regards, K.
Am 24-Nov-98 schrieb Tom Lane:
Karl Auer <auer@kom.id.ethz.ch> writes:
When I use the "-z" option (dump permissions)when dumping a database I
have, I get a segfault and no output.Are you on Postgres 6.4? I recall fixing several nasty problems with
permissions in pg_dump between 6.3.2 and 6.4.If you are on 6.4, could you use gdb or something to get a backtrace
showing exactly where pg_dump dies?
---
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer (auer@kom.id.ethz.ch) Geschaeft/work +41-1-6327531
Kommunikation, ETHZ RZ Privat/home +41-1-4517941
Clausiusstrasse 59 Fax +41-1-6321225
CH-8092 ZUERICH Switzerland
On Tue, 24 Nov 1998, Bruce Momjian wrote:
Date: Tue, 24 Nov 1998 11:08:42 -0500 (EST)
From: Bruce Momjian <maillist@candle.pha.pa.us>
To: auer@kom.id.ethz.ch
Cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] pg_dump - segfault with -z option[Charset iso-8859-1 unsupported, filtering to ASCII...]
hi.
I believe this will be fixed in the first 6.4 minor release. Should we
schedule 6.4.1 soon, folks.
Also, how about to include Jan's patch for LIMIT to 6.4.1 ?
Regards,
Oleg
-- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83
I have very simple database without triggers and also see
20:10[mira]:~/tmp>pg_dump -z guta > qq
Segmentation fault
Database = guta
+---------------------+----------------------------------------+
| Relation | Grant/Revoke Permissions |
+---------------------+----------------------------------------+
| groups | {"=","megera=arwR","er=r","httpd=arw"} |
| groups_pkey | |
| status | {"=","megera=arwR","er=r","httpd=arw"} |
| status_pkey | |
| stidx_status_id | |
| ugmidx_group_id | |
| ugmidx_user_id | |
| user_group_map | {"=","megera=arwR","er=r","httpd=arw"} |
| user_group_map_pkey | |
| users | {"=","megera=arwR","er=r","httpd=arw"} |
| users_pkey | |
|
Regards,
Oleg
On Tue, 24 Nov 1998, Tom Lane wrote:
Date: Tue, 24 Nov 1998 11:25:46 -0500
From: Tom Lane <tgl@sss.pgh.pa.us>
To: auer@kom.id.ethz.ch
Cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] pg_dump - segfault with -z optionKarl Auer <auer@kom.id.ethz.ch> writes:
When I use the "-z" option (dump permissions)when dumping a database I
have, I get a segfault and no output.Are you on Postgres 6.4? I recall fixing several nasty problems with
permissions in pg_dump between 6.3.2 and 6.4.If you are on 6.4, could you use gdb or something to get a backtrace
showing exactly where pg_dump dies?FWIW, I currently use -z routinely, but my database is probably even
simpler than yours ... no triggers, for example. My guess is pg_dump
doesn't work for permissions attached to a trigger, or something along
that line.regards, tom lane
_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83
Bruce Momjian <maillist@candle.pha.pa.us> writes:
pg_dump should not lose it to the extent of segfaulting :-)
I believe this will be fixed in the first 6.4 minor release.
If you meant that it has already been fixed, I don't think so.
I see only one post-6.4 patch so far against pg_dump, and it fixes
a wrong-output kind of problem, not a core-dump kind of problem.
BTW, is Oliver intending to try to fix pg_dump's inherited-constraints
problems in time for 6.4.1, or is that a longer-range project?
regards, tom lane
Import Notes
Reply to msg id not found: YourmessageofTue24Nov1998110842-0500199811241608.LAA04238@candle.pha.pa.us | Resolved by subject fallback
Oleg Bartunov wrote:
On Tue, 24 Nov 1998, Bruce Momjian wrote:
I believe this will be fixed in the first 6.4 minor release. Should we
schedule 6.4.1 soon, folks.Also, how about to include Jan's patch for LIMIT to 6.4.1 ?
No!
Should be put out as a separate patch. We forgot about the
initial v6.4-feature-patch I created over that branch/tag
discussion. I still have it here - who can put it onto the
ftp-server?
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck@debis.com (Jan Wieck) #
On Tue, 24 Nov 1998, Jan Wieck wrote:
Oleg Bartunov wrote:
On Tue, 24 Nov 1998, Bruce Momjian wrote:
I believe this will be fixed in the first 6.4 minor release. Should we
schedule 6.4.1 soon, folks.Also, how about to include Jan's patch for LIMIT to 6.4.1 ?
No!
Should be put out as a separate patch. We forgot about the
initial v6.4-feature-patch I created over that branch/tag
discussion. I still have it here - who can put it onto the
ftp-server?
You :) ~pgsql/ftp/pub/patches is writable by those in group
pgsql, which is all those wiht comitter's access...gets wiped out after
each release is made though, as its only pertinent to the current
release...
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
Tom Lane wrote:
BTW, is Oliver intending to try to fix pg_dump's inherited-constraints
problems in time for 6.4.1, or is that a longer-range project?
I hope to fix it quickly, since I want to back port a good pg_dump into
Debian's 6.3.2 before I release a 6.4 for Debian.
If anyone else can fix it, don't wait for me to find out how!
--
Oliver Elphick Oliver.Elphick@lfix.co.uk
Isle of Wight http://www.lfix.co.uk/oliver
PGP key from public servers; key ID 32B8FAA1
========================================
"Jesus saith unto him, I am the way, the truth, and the
life; no man cometh unto the Father, but by me."
John 14:6
Tom Lane wrote:
I have found one cause of sometimes-but-not-always coredumps in
pg_dump -z. Please apply the following patch and let me know whether
things get better for you.
I have applied the patch and test it against the same database.
Now it's ok, no more core dumps, thanks a lot.
The ACL code in pg_dump.c looks really butt-ugly ... I think I will
rewrite the whole thing this afternoon ... but this one bugfix may be
enough to get you going for now.
If you are going to rewrite some of the portions of pg_dump, I would
like to ask you to include that tiny patch that makes pg_dump write for
table structures just 1 field per line (inserting \n\t after every
field) in order to get a better look of the file. The current version is
giving a extremely long line for tables and it's somehow difficult to
watch or edit it.
All the best,
--
Constantin Teodorescu
FLEX Consulting Braila, ROMANIA
Import Notes
Reference msg id not found: 11427.912882040@sss.pgh.pa.us | Resolved by subject fallback