Thread: 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
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
[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, Pennsylvania19026
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
Bruce Momjian <maillist@candle.pha.pa.us> writes:
> Should we schedule 6.4.1 soon, folks.
I still have about 10 things on my to-do-for-6.4.1 list, and no hope
of doing any of 'em before this weekend. If "soon" means "a couple
of weeks", then fine ...
regards, tom lane
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 option
>
> 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
>
_____________________________________________________________
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
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, Tom Lane wrote:
> Bruce Momjian <maillist@candle.pha.pa.us> writes:
> > Should we schedule 6.4.1 soon, folks.
>
> I still have about 10 things on my to-do-for-6.4.1 list, and no hope
> of doing any of 'em before this weekend. If "soon" means "a couple
> of weeks", then fine ...
What's on that scheduale? Anything we can help with?
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
The Hermit Hacker <scrappy@hub.org> writes:
>> I still have about 10 things on my to-do-for-6.4.1 list, and no hope
>> of doing any of 'em before this weekend. If "soon" means "a couple
>> of weeks", then fine ...
> What's on that scheduale? Anything we can help with?
Here's my unvarnished to-do list. Most of it is configuration checks
that I figured I was in a good position to test (particularly the HPUX
items), but if you feel that I'm holding things up then feel free to
take a couple...
Actually, what I was kind of hoping *you* would work on is the
process-title-setting issue, since you had once indicated you'd
have a go at that for 6.4.1. I still think we need to snaffle
the process-title code from sendmail. What we have now doesn't
manage to change the ps listing on HPUX, and a couple of other
OSes too if I recall the discussion properly.
regards, tom lane
Auer reports segfault with pg_dump -z ... wtf?
HPUX FAQ! Ought to document yacc issues for HPUX 9. HP's lex doesn't
seem to work either, under both 9.* & 10.*. If you don't install patch
PHSS_4630 on HPUX 9, rint() is broken which leads to weird bugs in
datetime.
Update FAQ_CVS, also web page if not same file --- 1.9 is obsolete.
postmaster.c's fflush(NULL) doesn't work on SUNOS ... seems safe to
just fflush stdout and stderr instead. Worth making a configure test?
11/24 msgs
float8 regress test, pow, exp problems --- 11/18, 11/24 msgs
configure should unset USE_TK if X stuff not found. Cf. situation on
csp linux box, which has Tcl but no X.
configure.in ought not have a hardwired set of assumptions about what
the template file can define ... why not just read what's there, for
pete's sake? Proposed to list 11/22/98.
make install in doc failed on hpc200. Likely cause: no "zcat" in path.
Need to use autoconf to look for gzcat or zcat.
bogus selection of template when .similar entry includes partial rev
number --- see ts' msg of 11/19 8:44. Note that second try tries
to match without regard to version number, which is good ... it just
goes too far when there are multiple possibilities in .similar.
Note the wrong fix here could break HPUX --- might want to delete
rev number from hp line in .similar. (Fixed 11/22, I think.)
hpux 10.01 does not have POSIX signals? Perhaps we ought to use
autoconf to detect whether system has SA_RESTART... trick here is
that Makefile.hpux needs to know it too, to adjust library link order.
So would need to set info in both Makefile.global and config.h.
Could get rid of -DHPUX_10, which'd be a good idea anyway (in fact,
it might be possible to stop calling uname at all in Makefile.hpux,
which'd be a performance win).
NOTE: make sure template file or Makefile.port can override autoconf decision
in either direction (or at least the no-posix direction)... Makefile.port
can't do it because of config.h dependency. See pgsql msgs of 10/30.
Why does configure want libcurses to be included? Causes problems
in Makefile.hpux for HP10.. Could suppress libBSD instead of adding
an extra -lc pass if we got rid of curses. (libBSD only has signal
stuff.) Looks like libreadline requires either libtermcap or libcurses,
whichever is available on a given platform. Safest thing might be to
just put -lBSD in front of -lc ... Cf msgs 10/31 to 11/1.
%.sl rule in Makefile.hpux is probably not needed anymore?
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 isthat 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 ID32B8FAA1 ======================================== "Jesus saith unto him, I am the way, the truth, andthe life; no man cometh unto the Father, but by me." John 14:6
> > What's on that scheduale? Anything we can help with?
I've made a few fixes, and have one more on my list for v6.4.x:
Update contrib/linux startup scripts (someone had modified them to give
both sh and csh examples, but the labeling is scrambled).
Won't get to it until next week, but it isn't critical to a release
either...
- Tom
> I've made a few fixes, and have one more on my list for v6.4.x:
Never mind. I went ahead and committed the updates for this.
- Tom